Re: [PATCH v4 5/6] log: speed up --follow following renames for non-linear history

[Patrick Steinhardt <ps@pks.im>]

On Fri, Oct 30, 2026 at 09:09:11PM +0100, Miklos Vajna wrote:
> diff --git a/log-tree.c b/log-tree.c
> index 0aa27fb210..0dc71be61e 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -1153,6 +1169,29 @@ void release_follow_pathspec_slab(struct rev_info *opt)
>  	FREE_AND_NULL(opt->follow_pathspec_slab);
>  }
>  
> +/*
> + * When the path in a merge is the same as in 'same', does the path still need
> + * renames to be followed in 'parent'? Only if the merge has the path, 'parent'
> + * doesn't have it, but its fork point with 'same' had it, e.g. 'parent'
> + * renamed the path.
> + */
> +static int follow_needs_renames(struct rev_info *opt, struct commit *parent,
> +				struct commit *same, const char *path)
> +{
> +	struct commit_list *bases = NULL, *base;
> +	int ret = 0;
> +
> +	if (commit_has_path(opt, parent, path) ||
> +	    !commit_has_path(opt, same, path))
> +		return 0;
> +	if (repo_get_merge_bases(opt->diffopt.repo, parent, same, &bases) < 0)
> +		exit(128);
> +	for (base = bases; base && !ret; base = base->next)
> +		ret = commit_has_path(opt, base->item, path);
> +	commit_list_free(bases);
> +	return ret;
> +}

With unrelated histories this would return no bases at all, and hence
we'd always return 0 in such a case. But 304812ed33d (log: improve
--follow following renames for non-linear history, 2026-06-22)
explicitly mentioned the use case of sub-tree merges of unrelated
histories, so isn't this a regression?

Patrick