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:

> On Mon, Feb 25, 2008 at 4:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> ...
>>  > Is this really that useful?  Where is having the tag and the commit
>>  > SHA-1 both useful?
>>
>>  I had the same question.  The only place that I find this could
>>  be useful is when you tag, build and install, and then find
>>  glitches before pushing the results out and rewind, rebuild and
>>  re-tag.  I unfortunately have this issue almost all the time.
>>
>>  But even then, I would probably not rely on this patch.
>
> This can be usefull when more than one person can make "official" tags
> (or nobody), and then you have a uniqe idendifier with a descriptive
> name.

That's backwards.  If you want reliable unique identifier, you
would use 40-hexdigit.  If you want human readable, you would
use tags, and if you allow different people to distribute tags
with the same name that point at different things, _you_ have a
problem at higher level.

By the way, I think the naming "git describe" does is not quite
right.  The name of the tag _usually_ matches its path under
refs/tags/ by convention, but the code seems to trust the path
and does not seem to examine what the actual tag name in the
annotated tag is.

I think it should name commits based on the real tag name, at
least when it is only using annotated tags (i.e. the default
mode of operation).