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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 17, 2015, 20:28 UTC
Message-ID: <xmqqoadobz0f.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20151217064706.GA3531@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 20 quoted lines

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