On Mon, Apr 25, 2011 at 10:29:53PM +0100, Ben Hutchings wrote: > On Mon, 2011-04-25 at 22:25 +0200, Adam Borowski wrote: > > On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote: > > > If versions are not ordered without the inclusion of a commit hash, they > > > are not ordered *with* it (except by chance). > > > > Remember that version numbers have two purposes: > > 1. ordering > > 2. uniquely referencing a snapshot of source (blessed as a release or not) > > > > I'd call 2. more important than 1. > > It's not very important in the Debian archive. Telling someone "the bug is in a version I pulled from the VCS but didn't bother noting down which version it was" is not very useful. > > > But it is not possible for a branch head to be in two different > > > positions at different times which 'git describe' will distinguish only > > > by the hash, unless it is rebased. > > > * resetting to another version of the branch that has the same commit count > > * two developers or one developer with two machines or directories > > * many, many other ways > > > > Mere count of commits is pretty worthless in a distributed system. > > If your upstream is pulling such tricks then you cannot use this type of > version *with or without* the hash, because it will not be ordered > properly. You would have to use a date/timestamp. Eh? It is exactly why the hash is there! No matter how many commits were done at a particular date, and whether the commit was cherry-picked, rebased or tossed around in other ways, a hash will let you tell which exactly version it is. A date or timestamp will not. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice.
Attachment:
signature.asc
Description: Digital signature