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

From: Miklos Vajna <vmiklos@collabora.com>
Date: May 30, 2026, 06:28 UTC
Message-ID: <ahqDqSH7yfYVOOyE@collabora.com>
In-Reply-To: <ahFDgq4TAcs29zCA@collabora.com>

Hi Jeff,

On Sat, May 23, 2026 at 08:04:50AM +0200, Miklos Vajna <vmiklos@collabora.com> wrote:

Show 19 quoted lines

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