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

Previous thread: Re: git-email automatic --to detection? by John Goerzen on Monday, February 25, 2008 - 1:02 pm. (2 messages)

Next thread: [RFC] Build in clone by Daniel Barkalow on Monday, February 25, 2008 - 2:12 pm. (47 messages)
From: Junio C Hamano
Date: Monday, February 25, 2008 - 1:11 pm

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.



-

From: Santi Béjar
Date: Monday, February 25, 2008 - 1:51 pm

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


If you always use "git describe --long" it is globally unique, as long as sha1



Maybe.

Santi
-

Previous thread: Re: git-email automatic --to detection? by John Goerzen on Monday, February 25, 2008 - 1:02 pm. (2 messages)

Next thread: [RFC] Build in clone by Daniel Barkalow on Monday, February 25, 2008 - 2:12 pm. (47 messages)