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

[Miklos Vajna <vmiklos@collabora.com>]

Hi Jeff,

On Sat, May 23, 2026 at 08:04:50AM +0200, Miklos Vajna <vmiklos@collabora.com> wrote:
> > There might be a more useful rule like: if the path is untouched versus
> > the merge result in all parents but one (i.e., TREESAME), then choose
> > the parent where it was changed, including any --follow processing.
> 
> I like this idea: it keeps working with the subtree use-case I have in
> mind and goes back to not change behavior when the file has history on
> multiple parents.
> 
> > So I dunno. Probably some experimenting could yield more analysis there,
> 
> I think requiring TREESAME for all but one parents is too strict, since
> a subtree merge will look like an addition vs the first parent and will
> look like a rename on the first parent. It seems to me that handling
> addition as TREESAME can be correct: if the file was just added, that
> suggests it has no prior history.
> 
> So a slightly relaxed rule could be: if the path is untouched or just
> added versus the merge result in all parents but one, then choose the
> parent where it was changed, including any --follow processing.

Could you please comment on this, if this tweaked rule and its
implementation in the patch looks OK to you? Let me know if I should
just wait some more.

I would hope this addresses your concern where naively following an
other parent just makes one use-case better and can be worse in other
cases.

This also explains why the normal history simplification is not enough
here: the "added vs parent" is a change that is not interesting in this
case, but is more than TREESAME.

Finally, because I forgot to react to that earlier: I'm not against the
idea to attempt to improve --follow work better when visiting a tree of
commits in general, but sounds like a larger rework, so it would be nice
to have a fix for the subtree use-case first.

Thanks,

Miklos