Re: [PATCH v6 4/4] branch: let --delete-integrated find branches merged onto changed files

[Jasper Mayone <me@jaspermayone.com>]

Hi Harald

On Sat, Nov 1, 2026 Harald Nordgren via GitGitGadget wrote:
> +static int merge_keeps_upstream(const struct branch_change *change)
> +{
> +	mmfile_t base, upstream, branch;
> +	mmfile_t result = { 0 };
> +	int ret;
> +
> +	repo_read_index(the_repository);

This runs once for each changed file at each candidate commit. After
the first call, read_index_from() returns early, but repo_read_index()
still calls clear_skip_worktree_from_present_files() every time. In a
sparse checkout, that walks the index and can lstat() the
skip-worktree paths again for each merge. Could the index be read once,
before the walk in find_landed_commits()?

This also answers only half of Junio's question on v5. The attributes
now come from the index of the current worktree, not from the upstream
commit. A merge driver that is set only upstream is ignored, and in a
bare repository the index is empty, so no attributes apply. That can
be the right choice, but I think the commit message should say so.

> +test_expect_success '--delete-integrated deletes a squash merged branch after upstream changed the same file' '

All the tests for the new code path expect a deletion. I added these
cases locally on top of v6, and all of them keep the branch, as
expected:

 - upstream changed other lines of the file, but the branch was never
   merged
 - upstream has only one of the two hunks of the branch
 - upstream changed the same line in a different way, so the merge
   conflicts

A test where the merge does not leave upstream unchanged would protect
the behaviour that matters most here, which is to keep work that did
not land. I am happy to send the tests if they help.

With those points, the patch looks good to me.

Thanks
Jasper