On Mon, Feb 25, 2008 at 9:11 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Santi Béjar" <sbejar@xxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
