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

>
> Hi Phillip,
>
> > Le 16 sept. 2026 à 09:35, Phillip Wood <phillip.wood123@gmail.com> a écrit :
> >
> > Hi Ben
> >
> >> On 15/09/2026 22:16, D. Ben Knoble wrote:
> >> 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.
>
> Wow, I wish I’d had this info this morning! I spent a couple hours trying to understand this flow and still don’t have it in my head :) Thanks for the pointers.
>
> With the way I batch my side project time, it’ll be tomorrow before I get to trying to make and test patches for this, but I’ excited now.
>
> I may try to summarize my own notes (= questions about the existing code) and send those out later today, though, since I’d love to make my understanding line up with yours!
>
> >> 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.
>
> Yeah, that abort bit makes sense. I wonder if we should have had a better side-channel for communicating that, but I’m a bit too afraid to touch that for now ;)
>
> > Thanks
> >
> > Phillip
>
> Thank *you*!