Re: [PATCH v4 6/6] log: fix --follow following an edit on a side the merge did not take

[Miklos Vajna <vmiklos@collabora.com>]

Hi Patrick,

On Fri, Nov 06, 2026 at 03:14:17PM +0100, Patrick Steinhardt <ps@pks.im> wrote:
> > Fix the problem by also searching for renames when the merge base
> > doesn't have the path, but the parent changed a file since the merge
> > base that the merge no longer has: only such a file can be the old name
> > of the path that still needs to be followed in the parent.
> 
> This isn't true though in the case where you copy a file though, is it?
> E.g. the following test case is exactly the same as the one you add in
> this commit, but instead of using a rename we use a copy:

You're right, I didn't consider copying. I've added your test to 1/5 and
fixed 5/5 in v5 to handle this correctly.

The pre-filter now also takes a file into account that the merge still
has, but with the version of the other side, and the rename check now
also detects copies. This makes the linux.git case take about 42s,
instead of 37s here.

Thanks,

Miklos