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

Jeff King [off-list ref] writes:

When we unwrap a tag to find its commit for a traversal, we
do not propagate the "name" field of the tag in the pending
array (i.e., the ref name the user gave us in the first
place) to the commit (instead, we use an empty string). This
means that "git log --source" will never show the tag-name
for commits we reach through it.

This was broken in 2073949 (traverse_commit_list: support
pending blobs/trees with paths, 2014-10-15). That commit
tried to be careful and avoid propagating the path
information for a tag (which would be nonsensical) to trees
and blobs. But it should not have cut off the "name" field,
which should carry forward to children.
...
This was reported several weeks ago, but I needed to take the time to
convince myself this wasn't regressing any cases. I'm pretty sure it's
the right thing to do.

The regression is in v2.2.0, so this is not urgent to make it into v2.7
before release, but it is definitely maint-worthy.

Makes sense, and I agree.

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).

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