Re: Referring to revisions in the git future

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > >  >> address@hidden:/usr/local/tmp/git$ git describe 
 > >  >> v2.1.0-rc2-3-g67de23d
 > 
 > >  > Maybe I'm blind, but I can't see anything like a sequential version
 > >  > number in that string.

Unlike the other commenters, I will tell you that it is
"v2.1.0-rc2-3".  git describe works such that as long as you know
where the tags are relative to each other, you will be able to order
them.  It can't be used for computing bisects, of course, but
"v2.1.0-rc2-3" vs. "v2.0.9-4" tells you that these commits are close
to each other indeed.  That's useful, although I doubt you'll find it
terribly useful.

That's assuming they're on the same branch (although the usual
semantics of release versioning suggests that even on different
branches they're likely to be only a small patch apart).  Also there
may be un-orderable tags like "acm-forget-me-not".

The "not on same branch" issue applies to bzr, as well, of course, but
bzr encourages focus on the mainline.  With all due respect to Barry,
I disagree that it's the most natural way to work all of the time, and
I suspect that with the transition to git you will start seeing more
complex branching structure.  This will lead to more off-trunk
references and more cross-branch comparisons.

In any case, the git transition is a done deal, so you will really be
a lot happier if you focus on how you can make use of SHAs more
effective for you rather than on the essential wonderfulness of
revnos.