Stephan Beyer <s-beyer@xxxxxxx> writes: > This led to the idea to have something like "git stash --continue"[1] > that would expect the user to "git add" the resolved files (as "git > status" suggests) but then leads to the expected result, i.e. the index > being the same as before the conflict, the stash being dropped (if "pop" > was used instead of "apply"), etc. > > Likewise, some "git stash --abort"[2] might be useful in case you did > "git stash pop" with the wrong stash in mind. > > What do you think about that? "git stash pop --continue" (and "git stash apply --continue") would make quite a lot of sense. I like it very much primarily because it will give us an opportunity to correct a major UI glitches around applying stashed changes to the working tree. Don't people find it strange that "stash pop" that applies cleanly would not touch the index, leaving (an equivalent of) the changes stashed earlier floating in the working tree, but "stash pop" that conflicts and needs a three-way merge touches the index and the usual way of concluding the manual conflict resolution is "git add" the paths, meaning that the changes that were not ready hence floating in the working tree back when the stash was made goes into the index when the user concludes "stash pop"? With an explicit "--continue", we can fix that so that we reset the index to the HEAD. That way, whether the changes have conflict with the HEAD's tree or not, the end user after "stash pop" will see the changes in the working tree and "git diff" (no HEAD argument or "--cached" option) will consistently show what came from the stash.