Re: [PATCH] revision.c: propagate tag names from pending array
From: Jeff King <hidden>
Date: 2016-06-15 23:07:30
On Thu, Dec 17, 2015 at 12:28:48PM -0800, Junio C Hamano wrote:
By the way, a totally unrelated niggle I have with 2073949 is this.
$ git describe --contains 2073949
v2.3.1~3^2~4
while as you said, this dates back to at least v2.2.0-rc0
$ git tag --contains 2073949
v2.2.0
v2.2.0-rc0
...
v2.7.0-rc1
That "describe --contains" output comes from "name-rev --tags", and
I need to force it to use v2.2.0-rc0 as the source of naming, i.e.
$ git name-rev --refs=refs/tags/v2.2.0-rc0 2073949
2073949 tags/v2.2.0-rc0~13^2~9
to get what I would expect to be more useful.
I know "name-rev --contains" wants to describe a commit based on an
anchor point that is topologically closest, and even though I do not
offhand think of any, I am sure there are valid use cases that want
to see the current behaviour. But from time to time, I wish it did
its naming taking the topological age of the anchor points into
account. If a commit is contained in v2.2.0-rc0 and onward, even
though v2.0.0-rc0~13^2~9 describes a longer path from v2.0.0-rc0
than v2.3.1~3^2~4 is from v2.3.1, I often want to see the name based
on the "oldest" tag (if such a thing exists, and for older commits
in this project, it always is the case, I think).Yes, I agree (and judging by the number of "git describe is confusing" threads over the years, I think it is not just us). I rarely use "git describe --contains" myself. What I typically use (and how I arrived at v2.2.0 in this instance) is: git tag --contains "$@" | grep ^v | grep -v -- -rc | sort -V | head -1 But there are some git-specific assumptions in there. -Peff