From: Junio C Hamano <junkio@cox.net>
Date: Sun, 25 Dec 2005 09:44:10 GMT
Subject: Re: Add a "git-describe" command
Message-ID: <7vr781o6j9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0512241939490.14098@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

> My real goal was to see a real meaningful version when I do "git 
> --version". I just hate how it normally just says it's version "1.0.GIT", 
> and I have no idea how new/old it really is.

Hmph.  I am not so interested in "git --version", but I find
git-describe to be pretty attractive.

Last night I proposed to tighten pack naming which would promote
so-far just a convention to a rule, which would introduce an
backward incompatibility and wanted to know which released
versions are affected.  With git-whatchanged I can identify the
exact commit that changed the packname SHA1 computation with
ease:

        $ git whatchanged --abbrev --pretty=oneline \
          -S'	sorted_by_sha = create_sorted_list(sha1_sort);
                SHA1_Init(&ctx);
                list = sorted_by_sha;
                for (i = 0; i < nr_objects; i++) {
        ' HEAD -- pack-objects.c
        diff-tree 84c8d8a... (from 9cf6d33...)
        Fix packname hash generation.
        :100644 100644 3d62278... ef55cab... M	pack-objects.c

and from that I would have been able to find that the change was
between 0.99.8 and 0.99.9:

        $ git describe 84c8d8a
        refs/tags/v0.99.8-g84c8d8ae

I used "git-show-branch $that_commit tags/v0.99.?" to get that
information instead, but git describe would have been very
useful.