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

[Junio C Hamano <gitster@pobox.com>]

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

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