Re: [PATCH] Teach git-describe --long to output always the long format

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 26, 2008, 09:19 UTC
Message-ID: <7vy7986pnc.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <8aa486160802251251u74a19b93l77ca3930d2387cb8@mail.gmail.com>

"Santi Béjar" <sbejar@gmail.com> writes:

Show 11 quoted lines

>>  Why can't you solve it?  Your example of two people giving the
>>  same name to different things shows a lack of communication
>>  between developers, and as long as you and the other guy are
>>  talking with each other the problem can be solved, can't it?
>
> But there are times when you can't/don't want to communicate
> (private/testing/forks, whatever).
>
> Anyway, even if this problem is solved I feel more confortable
> with a version in my binary (and output) with a descriptive
> name and a revision id.

As I think about it more, I think that such a lack of communication is not something "git describe" should even claim to help working around.

But a uniform-looking describe output does have certain attractiveness:

	$ git describe --long 31e0b2c 6c0f869
        v1.5.4.3-0-g31e0b2c
        v1.5.4.3-1-g6c0f869

So I have quite a big problem with your commit log message, even though I am starting to like what it does. Perhaps this would be more to the point.

    git-describe: --long shows the object name even for a tagged commit
    
    This is useful when you want to see parts of the commit object name
    in "describe" output, even when the commit in question happens to be
    a tagged version.  Instead of just emitting the tag name, it will
    describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2
    that points at object deadbeef....).

By the way, I do not think "long" is what it does. It does not even show the full object name unless you tell it to with another option (i.e. --abbrev). The flag tells the command to use the normal output format that is used to describe most other commits (untagged ones), and signal the "taggedness" with the count part being "-0-".

Perhaps --nonexact-format, or even --redundant-output?

Hmmmmm... "--always-count", as it is about always using the counted format (which is the "normal" output format)?

I know, I am bad at naming, so I'll park the commit in 'pu', with option name kept as "--long" as in your patch.