When I pop a stash and get a conflict, the popped stash changes end up in the work tree with the usual (Resolve) (Stage) buttons. When I then resolve/stage stuff, it seems SM has forgotten that I was working with a stash pop. It just staged that stuff for doing some normal commit. There is no way to “resume stash popping”. And the stash is just lying there like before i popped it. So I have to kind of stage the changes, and then unstage them to get them back as normal working tree changes, and then manually drop the stash after im done. Feeling slightly confused. Maybe git doesnt support this thing very well.
What you’re seeing here is a property of
git itself and not of Merge; Merge acts as sort of a wrapper over the command line
git tool (and actually invokes it to make changes) and thus mimics what
git would do and show in a similar situation.
stash pop a stash and the operation results in a conflict, then a couple of things happen.
git will not automatically remove the
stash for you as it would if the stash applied cleanly; presumably this is to ensure that you don’t lose any code. As such regardless of how you proceed from this point forward you to need to manually
git stash drop the stash afterwards to get rid of it.
Secondly, you end up in the state that you mentioned where you are asked to resolve the conflicts in the merge. A part of general
git conflict resolution is that you stage files after you’ve resolved the conflicts to let
git know that you’ve resolved them and want to keep the result. I would guess that the most expected workflow in this case is perhaps that you actually want to permanently commit the results, though I can’t think of any time personally where that has ever been the case.
In any event, as outlined in this SO answer, the general order of operations when a stash doesn’t apply cleanly would be to use
git reset to unstage all of the changes (unless you actually want to make a commit) and
git stash drop to drop the stash manually
As such what you’re currently doing seems like the correct way to do what you want, even though it seems a little convoluted (although at some level that applies to a lot of
git in general ).
Wow, thanks for a great reply!
Looking at your SO answer link, it seems a better workflow from the commandline is to resolve through whatever mergetool – and then
git reset the files to make they just sit there as regular changes. My conclusion is then that SM could offer such a button along with (resolve) (stage) or maybe replace the stagebutton with a new button.
I understand this solution might be slightly confusing, and requires some though into how to communicate this to the user in the UI. And its probably not a big priority. But, do you think my understanding is correct?
And on another note - do you know of a workflow to help with the git reset of the files in SM? Thanks again
I imagine a potential pitfall of trying to treat this specially is that there’s nothing about the
git responses or the state of the repository that tells you or anything else (including Merge) that you were in the middle of a
stash pop when the conflict happens. If you happened to do it from Merge it could remember that’s what you did, but AFAIK the aim is to make Merge sit “on top” of Git, in which case if you did that operation in the console and then used Merge as the merge tool, it wouldn’t be able to tell that’s what happened.
The context menu for commits in the commit tree as well as the “Three Dots” menu that’s visible in the top right when you’re looking at a commit contains reset operations; the
Reset BRANCH to this Commit > Mixed (Default) menu entry represents what would happen if you just did a
git reset from the terminal, so you can use that.
Following the instructions in the post below, you can also add a
Git Reset action to the command palette as well, which may be easier to trigger (particularly if you tend to use the keyboard).
Thanks again for quality replies. I got everything I wanted. I stand humbly in your wisdom!