Having just been in this situation, I think you are missing the problem. The problem is that after "git stash pop" has conflicts, the user does not know the st

Having just been in this situation, I think you are missing the problem. The problem is that after "git stash pop" has conflicts, the user does not know the state that of the system, and thus does not know how to react. In my case, I temporarily changed a number of tracked "build" files that are custom my system and that I do not intend to check in for others to use. I was then asked to test a branch that someone else had checked in. My desire was to stash my local changes, check out their branch, and reapply my local changes to build it. But after "git stash pop" failed I had trouble figuring out the state of the system. I couldn't make any sense out of the messages that appeared, and fell back on Googling for answers. My expectation was that the stash would have been popped, that I would open the build files, find some lines about merge conflicts, that I would manually fix them in an editor, and then I would rebuild. Instead, it does "something else", and hard part was figuring out what that "something else" was. There are probably excellent reasons for the exact behavior, but I'd ask: where is it made clear to the user what happens when "git stash pop" experiences conflicts? Where does it say to do what you suggest? Separately, if you happen to know, how should I best deal with this personally frequent situation that I have a small "patch set" that I want to be able to apply to arbitrary branches, but that I have no intention of ever making visible to other users? I'm sometimes tempted to fall back on "git diff > patch.local" and manage it manually, but there must be a better way.