Re: Referring to revisions in the git future.

[David Kastrup <dak@gnu.org>]

Alan Mackenzie <acm@muc.de> writes:

> Yes, that sounds like an excellent reason for using hashes.  But for many
> uses, a revision number is better.  bzr has them both.  git doesn't.

Git has "git describe" for getting a sequence-based decription.  It's
used for informal version numbers, like for a self-compiled git as
opposed to an official release:

dak@lola:/usr/local/tmp/lilypond$ git --version
git version 1.9.1
dak@lola:/usr/local/tmp/lilypond$ ../git/git --version
git version 2.1.0.rc2.3.g67de23d.dirty
dak@lola:/usr/local/tmp/lilypond$ cd ../git
dak@lola:/usr/local/tmp/git$ git describe
v2.1.0-rc2-3-g67de23d

Nobody uses it in Email communication because there are no sufficient
upsides to it.  If you want to talk about a commit, you'll talk about

commit 67de23ddb1ed5471e302f6a84fae7a9037a0d980
Merge: f82887f 09898e7
Author: Junio C Hamano <gitster@pobox.com>
Date:   Sun Aug 10 11:03:03 2014 -0700

    Merge branch 'master' of git://ozlabs.org/~paulus/gitk
    
    * 'master' of git://ozlabs.org/~paulus/gitk:
      gitk: Updated Bulgarian translation (302t,0f,0u)
      gitk: Add keybinding to switch to parent commit

because that saves everybody the work of having to figure out the
details himself by asking his repositoty.  A serial number is not in any
manner more useful than a hash here.

I am not really interested in continuing this silliness since it is
totally irrelevant, anyway.  If you want to change Git's operation and
nomenclature, feel free to make your point on the Git developer list and
tell everybody there they are doing it all wrong.

-- 
David Kastrup