Re: Referring to revisions in the git future.

[Alan Mackenzie]

Hello, Óscar.

On Tue, Oct 28, 2014 at 11:54:19PM +0100, Óscar Fuentes wrote:
> 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.

We've more than one branch in our Emacs repository, yet the bzr revision
numbers are not in the slightest inconvenient.

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

That is a bit like saying, instead of saying "tomorrow at 8 o'clock",
which is horribly ambiguous, you should instead say at time 238707724383
(i.e. number of seconds after 1970-01-01, or whenever it was).  Changeset
IDs are good for some things, bad for others.

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

Are they going to enable the sort of conversation I exemplified above?

-- 
Alan Mackenzie (Nuremberg, Germany).