Re: Referring to revisions in the git future.

[Stephen J. Turnbull]

Barry Warsaw writes:

 > Sure, but [changing revision numbers is] rare and only happens with
 > some funky (and I'd argue incorrect directionally) merges.

Actually, it happens in *every* merge -- the local revnos are
obsoleted and turn into something meaningless in many cases (you get
the base, but who cares about that? -- it's whether the commit being
compared to is before or after the *merge* that matters).  And even on
the bzr list you'd occasionally see the "it's in my commit r666042"
"no, it's not, and that's not even your commit" "oops, push push must
push, try now" conversation.  Or worse "sorry, that's in the review
pipeline, wait for it" :-) conversation, but that was project-specific.

True, it only happens in the public repo if people merge public into
local and then push, and you can configure the public repo to refuse
such pushes (at least you can in bzr and hg, I'm not sure if git
supports this well even today).  But seriously, I'm frequently far
enough out of sync (say, 5 to 10 commits :-) that the revnos are just
as useless as SHA1s would be.  The overhead of pulling just to get the
commit under discussion swamps any difference in convenience as far as
I'm concerned.  YMMV, of course, that's just me.

 > And besides, those sequential numbers are only for our convenience,
 > right? ;)

Sure, and they're convenient mostly because you're used to them.  They
really don't have more content than SHA1s do, but they're easier to
read because they're decimal and relatively small.  I'm not going to
deny that, but I think everybody would be better off if some
infrastructure were created to make SHA1s easier to manipulate.

For example, in response to my earlier post, Stefan responded that
SHA1s aren't that easy to recognize and you'll get too many false
positives.  My initial rebuttal was "Eh?!", but a more constructive
response is, so we establish a convention of prefixing with "sha:" or
"SHA:".  The issue of "which repo" (especially for ELPA) is real, too,
but again context is likely to give you a very good first guess, and
after that you can configure some kind of variable to improve Emacs's
guessing.

This ain't rocket science, and it's the kind of thing Emacsen are
*very* good at.