From: Junio C Hamano Date: Mon, 25 Feb 2008 08:54:21 GMT Subject: Re: [PATCH] Teach git-describe --long to output always the long format Message-ID: <7vbq65ju0y.fsf@gitster.siamese.dyndns.org> In-Reply-To: <8aa486160802250034ncdf20b6s13856ca8612bc2ea@mail.gmail.com> "Santi Béjar" writes: > On Mon, Feb 25, 2008 at 4:08 AM, Junio C Hamano wrote: >> "Shawn O. Pearce" writes: >> ... >> > Is this really that useful? Where is having the tag and the commit >> > SHA-1 both useful? >> >> I had the same question. The only place that I find this could >> be useful is when you tag, build and install, and then find >> glitches before pushing the results out and rewind, rebuild and >> re-tag. I unfortunately have this issue almost all the time. >> >> But even then, I would probably not rely on this patch. > > This can be usefull when more than one person can make "official" tags > (or nobody), and then you have a uniqe idendifier with a descriptive > name. 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. By the way, I think the naming "git describe" does is not quite right. The name of the tag _usually_ matches its path under refs/tags/ by convention, but the code seems to trust the path and does not seem to examine what the actual tag name in the annotated tag is. I think it should name commits based on the real tag name, at least when it is only using annotated tags (i.e. the default mode of operation).