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