Re: path-restricted log vs. subtree merges

[Junio C Hamano <gitster@pobox.com>]

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

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