On 27 Mar 2009 at 13:49, Michael J Gruber wrote: > Ulrich Windl venit, vidit, dixit 27.03.2009 08:21: [...] > Keyword substitution and cvs/svn style version numbers are independent > issues. The sha1 describes a commit uniquely, one could use that as a > keyword. However version numbers and time stamps have the property of being at least partially ordered in respect of "newer/older". That property does not hold for SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-) > > Increasing version numbers are meaningless in a true DVCS world. What is > your 100th commit may not be someone else's, even if both your master's > heads are the same! This is why hg version numbers are a local thing. > They are merely a local shortcut for specifying a revision and serve the > same purpose as git's "backward" counts like HEAD~3 etc. Neither of them > work permanently, not even in a local repo, if you allow rebasing. Maybe I didn't fully understand, but having a version number that is larger than any parent's version numbers when doing a merge/commit doesn't look wrong to me. > > git rev-list HEAD|wc may produce something like it, but be sure to read > up on --sparse and --full-history. I'm not deep enough into it, yet. [...] Regards, Ulrich -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
