Autostash behavior with commit fixup

[praxxis]

First off, I'm really enjoying git-spice - it threads the needle of powerful and flexible while still allowing incremental adoption extremely well.

I've been playing with the new commit fixup command and noticed something surprising about the autostash behavior. Running the following:

echo "first file">first.txt && git add first.txt && gs b c first -m "first" 
echo "second file">second.txt && git add second.txt && gs b c second -m "second" 
echo "change" >> first.txt
echo "change" >> second.txt
git add first.txt
gs c f <choosing the `first` branch>

It fails with the following:

~/D/t/gs second $ gs c f
Pick a commit: 5e515f0
ERR Dirty changes in the worktree were stashed, but could not be re-applied.
ERR The following files were left unmerged:
ERR   - second.txt
ERR Resolve the conflict and run 'git stash drop' to remove the stash entry.
ERR Or change to a branch where the stash can apply, and run 'git stash pop'.
FTL gs: rebase onto new commit: first: dirty changes could not be re-applied

My assumption for how autostash would work in this situation is either:
The stash would be reapplied to the branch I ran fixup on (in this case second)
or
The stash would not be automatically applied at all, letting me control when to unstash it.

As it is you'd have to manually stash before running fixup if you have changes that span multiple branches in a stack.

[praxxis]

reporting this in the fixup issue instead