Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash

Matthieu Moy [off-list ref] writes:

Ramkumar Ramachandra [off-list ref] writes:

quoted

If it is 0 (which means that the rebase completely successfully), pop
the stash before exiting as usual.

And you're going to pop the stash even if no stash were triggered when
starting the rebase.

Really, think about it again: you're not going to guess whether you have
to unstash without storing this information somewhere. You may argue
about storing it outside the todolist, you can't unstash
unconditionally.

Yes, it can be part of todo, but it does not have to be.

Regardless of where the information is stored, implementing the last
step as "stash pop" will add a small inconsistency the end user
needs to be aware of.

Imagine "git rebase" stops, asks you to help with conflicts, and you
look at it, play with the working tree, and made a mess.  If this
was the last "stash pop" invocation, the way to go back and start
again is "reset --hard && stash pop".  For all the other steps, that
is not how the user goes back to the originally conflicted state in
order to retry from scratch.

Makes me wonder if the world were a better place if the rebase-todo
list were implemented as a dedicated stash and "rebase --continue"
were a mere "stash pop" followed by a commit if pop goes smoothly.

I am not suggesting to actually do so, but it is an intriguing
thought from the perspective of end user experience, isn't it?

In any case, I am not saying that it is a _bad_ thing to implement
the last "restore the WIP" stage as "stash pop". I am just pointing
out that the messaging needs to be done carefully to make sure the
user understands which one is which, as the way to deal with the
situation where it stops and asks the user for help would be
different from normal step in the rebase sequence that replays a
commit.