Re: [PATCH] Teach git-describe --long to output always the long format
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 25, 2008, 08:54 UTC
- Message-ID
- <7vbq65ju0y.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <8aa486160802250034ncdf20b6s13856ca8612bc2ea@mail.gmail.com>
"Santi Béjar" <sbejar@gmail.com> writes:
Show 16 quoted lines
> On Mon, Feb 25, 2008 at 4:08 AM, Junio C Hamano <gitster@pobox.com> wrote: >> "Shawn O. Pearce" <spearce@spearce.org> 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).