Re: "git describe" documentation and behavior mismatch

From: Daniel Knittl-Frank <knittl89@googlemail.com>
Date: Nov 30, 2017, 19:26 UTC
Message-ID: <CACx-yZ1dJuUj5mD6WE8yqZCPMK8q-yaJ0GKUSppZ7uDkqvJ5UA@mail.gmail.com>
In-Reply-To: <CACx-yZ10GiDT=dDeF1EUtM_K4nGd414SDfxLRqGWyXt0ub02Gg@mail.gmail.com>

On Thu, Nov 30, 2017 at 7:47 PM, Daniel Knittl-Frank <knittl89@googlemail.com> wrote:

Show 15 quoted lines

> […]
>
> Running the above commands in the git.git repository yields a different result:
>
>>     $ git describe --all --abbrev=4 v1.0.5^2
>>     v1.0.0-21-g975b3
>
> No "reference path" to see. It is however shown, when the output is a
> branch name:
>
>>     $ git describe --all --abbrev=4 origin/next
>>     heads/next
>
> Is this expected behavior? IOW is the documentation outdated or is the
> git describe command misbehaving?

Bisecting history goes as far back as Feb 2008: commit 212945d4a85dfa172ea55ec73b1d830ef2d8582f

> Teach git-describe to verify annotated tag names before output

The warning mentioned in the commit message has since been gone. So I guess the documentation is outdated? Nobody has complained for the past 9 years, so we could call this a "feature" :)

An interesting fact (and intentional behavior?) is that describing a commit with only a lightweight tag will properly display the tags/ prefix. I assume this is because the annotated tags only store the tagname without any ref namespace, which is then picked up by git describe and displayed.

I will try to come up with a patch for the man page.

Daniel

-- 
typed with http://neo-layout.org