Re: [PATCH] revision.c: propagate tag names from pending array

From: Jeff King <peff@peff.net>
Date: Dec 17, 2015, 22:14 UTC
Message-ID: <20151217221459.GB8150@sigill.intra.peff.net>
In-Reply-To: <xmqqoadobz0f.fsf@gitster.mtv.corp.google.com>

On Thu, Dec 17, 2015 at 12:28:48PM -0800, Junio C Hamano wrote:

Show 31 quoted lines

> 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