Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html