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:

>>  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.
>
> Yes, I have a "problem" at a higher level, but I cannot "solve" it.
> This patch "workaround" this "problem", we want all to be able to tag
> and have descriptive and uniqe names. I think git should allows us to
> work this way.

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?

SCM or any other tools may facilitate developer communication,
but it is not a replacement for communication.

Inside a local repository, git already allows you to:

 * prevent such a problem by not overwriting an existing tag
   unless you ask with -f; and

 * verify that the object a tag refers to is really the object
   you expect the tag to point at with "cat-file tag".

"git describe" output can be unique only within a local
repository, as it cannot read your mind and inspect random
repositories other people own.  In one repository, abbreviating
an object name to 4 hexdigits may be enough to make it unique,
but in another it may need 6 hexdigits.

If you are trying to guarantee uniqueness of something that
lives for a long time (e.g. release version number that is
embedded inside binaries, which is what you use "git describe"
to generate), _and_ if you worry about two people in different
repositories giving the same name to different things which
would introduce a bogosity to that long-lived name, you would
need a way that is external to the uniqueness guarantee "git
describe" can give.

I do not mind low-impact new options and new features like this.
Everybody loves bells and whistles.  But I do want valid use
cases attached to them so that (1) we can justify their
existence; and (2) we can document them to explain what purpose
they serve, to help people to decide when to use them.

I even suspect that the --long flag might be useful in some
situation, but I do not think "a tag with the same name" is one
of the problems this patch lets you solve or work around.

Jakub's "it looks more uniform and does not treat a tagged
version any specially" may probably be a better argument for
this new feature.  I dunno.