Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help