Re: [BUG] stash.index=true leaves a redundant stash entry after an autostash fast-forward

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Sep 16, 2026, 13:35 UTC
Message-ID: <56991232-5d16-41d1-9c7d-ca7ebdd9fce7@gmail.com>
In-Reply-To: <CALnO6CCkq7mjBUKxOYcwKX8=SrH441FuWopoGZutPk99JRTGUA@mail.gmail.com>

Hi Ben

On 15/09/2026 22:16, D. Ben Knoble wrote:

Show 5 quoted lines

> 
> I'm experimenting with something that swaps that out for a call to
> reset_working_tree(), but I don't think I've gotten it quite right for
> this bug yet (let alone run other test cases that might be affected by
> this change).

It looks like stash has its own unpack_trees() wrapper, so I think the simplest fix is to replace reset_head() with

	reset_tree(&c_tree, 0, 1);

Taking a step back, this code applies the stashed index changes into the current index, writes the result to a tree and then resets the index to HEAD. We could avoid touching the index at all if we used merge_incore_nonrecursive() to cherry pick the index changes instead. That way we'd get a proper three-way merge and avoid spawning subprocesses for "git diff-tree", "git apply --cached", and "git reset". We're already using merge_ort_nonrecursive() to merge the working tree changes in that function so we have nearly everything we need already set up to merge the index changes as well. Essentially, when merging the index, we just need to call merge_incore_nonrecursive() instead of merge_ort_nonrecursive() and use info->i_tree instead of info->w_tree.

> BTW, it's really weird to me that the reset manual doesn't mention all
> these "extra" cleanups reset does via remove_merge_branch_state()!

Agreed, I think it comes from "git foo --abort" calling "git reset (--merge|--hard)" though that doesn't really explain why a mixed reset also removes the branch state.

Thanks

Phillip

Show 13 quoted lines

>> Possible directions, in case they are useful: remove_merge_branch_state()
>> is about ending a merge, and `git stash apply --index` is not ending
>> one -- having stash's reset_head() avoid the branch-state cleanup, or
>> teaching an in-flight autostash apply to shield MERGE_AUTOSTASH, would
>> both close it.  Making apply_save_autostash_ref() tolerate a missing
>> ref would silence the error but leave the duplicate entry.
> 
> I also thought briefly about disabling stash.index for a merge
> autostash, but that's really papering over things, I think.
> 
> I'll keep noodling on this (hopefully tomorrow morning), but in the
> meantime input from others welcome :)
>