Re: Referring to revisions in the git future.

[Óscar Fuentes]

Hello Alan,

Alan Mackenzie <address@hidden> writes:

> Hello, Emacs.
>
> We are switching to git, soon.
>
> git doesn't have revision numbers.  Instead it uses cryptic identifiers,
> which are not very useful in day to day conversation.  A bit like in
> George Orwell's "Newspeak", where lingusists constantly removed words and
> meanings so as to render certain notions literally inexpressible, we seem
> to be faced with the same situation.
>
> On this list, one quite often sees statements such as:
>
>     "That was fixed in revision 118147, have you updated since then?"
>
> or
>
>     "The bug seems to have been introduced between 118230 and 118477.
>     Maybe you could do a bisect to track it down.".
>
> Is it going to be possible to express such ideas in our git world, in any
> meaningful way?  If so, how?  Does git have a useable way of mapping its
> cryptic revision identifiers to monotonically increasing natural numbers,
> or some other useable scheme?
>
> I have bad feelings about this.

Before switching to git mayself the lack of revision numbers was the
strongest perceived inconvenience. Afterwards, it wasn't that bad. First
of all, you need to realize the limitations of using revision numbers:
they are meaningful only on the context of a branch. As soon as you have
more than one branch and merge among them, revision numbers are an
inconvenience.

As you use Mercurial, which has revision numbers, the advice of the
Mercurial experts possibly have some weight for you:

http://mercurial.selenic.com/wiki/RevisionNumber

    Revision numbers referring to changesets are very likely to be
    different in another copy of a repository. Do not use them to talk
    about changesets with other people. Use the changeset ID instead.

OTOH, there was some discussion on this list about using some
tool-independent schema, using a combination of the author's e-mail and
a timestamp.