Re: On git 1.6 (novice's opinion)

From: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Date: Mar 27, 2009, 13:48 UTC
Message-ID: <49CCE72E.20081.258EE61F@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
In-Reply-To: <49CCCB3D.8010706@drmicha.warpmail.net>

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 ;-)

Show 7 quoted lines

> 
> 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