Re: Referring to revisions in the git future.

[David Kastrup <dak@gnu.org>]

Alan Mackenzie <acm@muc.de> writes:

> Hello, David.
>
> On Wed, Oct 29, 2014 at 09:50:28AM +0100, David Kastrup wrote:
>> Alan Mackenzie <acm@muc.de> 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.".
>
>> So what are people going to do with this kind of information?
>> Copy&paste it into some command line.  A 40-letter string works just as
>> well as a 6 letter string for that.
>
> Copy&paste using a mouse is a tedious operation which interrupts
> workflow.

So don't use a mouse.

> A number like 118230 can be easily memorised and typed in to a command
> line.

Frankly, memorizing something like revision ids is error prone and
dangerous.  If you memorize the first 6 characters of a commit id
instead, at least Git will complain if that identifies no unique commit.

> What else am I going to do with the information?  A revision number
> contains useful meta-information: how old the revision is (more or less),
> and whether it comes before or after another revision (more or less).

That's the kind of stuff I'd rather ask my version control system.

> In the above "fancy doing a bisect?" example, it's immediately clear
> that the bisect operation is going to be taking around 7 or 8
> repetitions, that clarity being more immediate and subconscious than
> calculated.  One can estimate, quasi subconsciously, whether the
> tedium involved in the bisection would be well spent, or whether some
> other approach would be better.

Well, feed those numbers to git bisect, and it will tell you right away
how many steps it will take.  Exactly.

> A revision number tells you how old the repository is.  With 118230,
> the repository is clearly decades old.  With 729, it might be as young
> as a few months.

I don't see you appending your birth date to your name, either.
Basically you are complaining that the commit SHA1 only provides the
commit SHA1 without additional literary value that one can approximately
deduce when brooding for hours over it rather than asking the version
control system.

But it is not intended to be a conversation piece.

> With revision hashes, all that information is absent.  To get it, one
> is forced to enter tedious command line commands, likely having to use
> a mouse to cut and paste the hash - twice.

Keyboard exists.

> It is analogous to being able to refer to people by their names,
> compared with having to use some sort of random identifier.

If you become acquainted with a particular revision number to a degree
that you develop a personal relation to it, chances are that this commit
was a bad idea.  Also chances are that you'll start recognizing the SHA1
after getting to see it for the twentieth time.

> Having revision numbers clearly works very well.

That reminds me of the rule-of-thumb for discovering errors in
mathematical proofs: just look for the first occurence of any of
"clearly", "trivially", "obviously", "it can be easily shown".

> bzr and hg both have them in addition to the universe-unique hashes.
> git is missing this useful feature.

And git clearly works very well since it is being used in large-scale
non-trivial projects with thousands of developers.

Feel free to use "git describe" yourself for getting a "human-readable"
"revision number".  But don't expect many others to follow that practice
enthusedly.

-- 
David Kastrup