Re: [PATCH] log: let --follow follow renames in merge commits

From: Junio C Hamano <gitster@pobox.com>
Date: May 19, 2026, 08:14 UTC
Message-ID: <xmqqjysz7r41.fsf@gitster.g>
In-Reply-To: <xmqqo6ib7vlp.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 9 quoted lines

>>> Could you please review this?
>>
>> I'm a bit confused regarding what can be a next step here. I
>> understanding you were away for 3 weeks, so there is a lot to process.
>> :-) Should I just wait more or should I resend this?
>
> Rather, ask other reviewers; when I do not comment on a patch, I
> often am not interested, or too busy and the change does not look
> interesting enough to me to make me drop what I am doing.

Addendum.  As I said in

    https://lore.kernel.org/git/xmqqqzni967o.fsf@gitster.g/

and the subsequent discussion concluded, the "==follow" checkbox feature is meant to work well only in a linear history, and that is inherent to the way it "follows" the single path.

It does not follow different pathname(s) while following a set of different histories merged, e.g., in a history like this (as usual time flows from left to right)

    ----o----A----o
                   \
                    M----o----o----o
                   /
    ----x----B----x

you may start following path F at the HEAD, and after crossing the merge M, one history may find out that path F came from path G. The traveral starts with "F" as the sole element in the pathspec, but once the traversal hits that commit (say, A), the traversal switches to use "G" as the sole element in the pathspec and follows the history down. Even if the other history (i.e., 'x' on the lower history) had path F all along, once the pathspec is swapped to follow "G" on the upper lineage of the history, traversal of the lower lineage that happens after the traversal passes 'A" _will_ try to follow "G" that may not exist at all. Or 'x' may have done the same rename from "G" to "F" at "B". Depending on the order in which "A" and any of these commits on the lower history are visited, the commit that is a child of "B" (which has the path at "F") may be visited after "A", in which case the path in question "F" will not be looked for in it.

A minor "tweak" that does not solve this inherent design issue does not interest me, so...