Re: path-restricted log vs. subtree merges

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 16, 2025, 19:44 UTC
Message-ID: <xmqqo6y0dal1.fsf@gitster.g>
In-Reply-To: <2d53bebd-e85e-7414-c7ba-bd1f31810cea@gmx.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 10 quoted lines

> I had a quick look at the relevant function (`try_to_follow_renames()` in
> `tree-diff.c`), and my intuition told me that
>
> - `choice = q->queue[0];` would need to be replaced with a loop that adds
>   the `q->queue` elements to a `strset`,
>
> - `!strcmp(p->two->path, opt->pathspec.items[0].match)` would need to be
>   scrapped in favor of testing in a loop whether `p->two->path` is matched
>   by any of `opt->pathspec.items` (because there would now be more than
>   1),

These are needed regardless of "following renames of directory". The fact that there is one single path being followed globally means that the current "check-box item" design of --follow-renames would not work in a mergy history, where the path that holds the contents being followed is called differently on different branches and given a name (either taking one of the names from these branches, or a nname entirely different from any of the ancestors) at the merge, or a path is renamed differently along the forked history, eventually getting merged back. Even in a "follow this single path" mode, you'd need the notion of "this is the path being followed while we are on this single strand of commits" that is kept per ancestors whenever you hit a merge while traversing from child to its parents.

The current "following single path" would need to be done correctly, and then "following more than one paths from anywhere in the tree" would fall out as a natural consequence once it is done. "following renames of a directory" would mostly be a special case of "following more than one paths from anywhere in the tree".

Thanks.