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

["Santi Béjar" <sbejar@gmail.com>]

On Mon, Feb 25, 2008 at 9:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "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?

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.

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

I know, but my problem is not lack of communication.

>
>  "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 always use "git describe --long" it is globally unique, as long as sha1
is globally unique (at least unique enough).

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

See above.

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

OK.

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

Maybe.

Santi