[experiment feedback] gs commit fixup

[abhinav]

This issue tracks the work to stabilize the 'gs commit fixup' experimental command introduced in #836.
Feel free to post feedback here if you use the experimental command.

Known issues (not all of these will be resolved before stabilization):

• Handling of conflicting changes: If staged changes cannot be applied to the destination commit without a conflict, we currently reject the operation. We should provide users the ability to resolve the conflict instead.
• Hooks: The operation does not invoke any Git hooks. We may want to invoke the "post-rewrite" Git hook.
• No edit: The command currently does not provide a means to edit the commit message for the commit that was fixed.

Fixed issues:

• Autostash support [experiment feedback] gs commit fixup #867 (comment)

[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.

[abhinav]

(Moved from separate comment)

@praxxis Thanks for the kind words, and for experimenting and reporting issues!
You're correct, that's a bug. It should switch back to second before popping the stash.
I have a good idea of how to fix this—will update this ticket/comment when that happens.

[abhinav]

Fixed in #868
Thanks!