That's exactly what I wanted! (Note that I'm not using -soft here, because if there are auto-merged files in your stash, they are auto-staged and thus you'd end up with these files being staged again after reset.)īut there's one more thing left: The man page for git stash pop reminds us that 'Applying the state can fail with conflicts in this case, it is not removed from the stash list. My working copy has not been changed, but the WIP commit is gone. How do I get rid of that commit without modifying my working copy? Wait, there's a popular command for that! git reset HEAD^ Now my working copy is in the state I want, but I have created a commit that I don't want to have. Git commit -a -m WIP # (short for 'work in progress') I decided to go with what Git suggested: I resolved the conflict and committed: vim src/js/ No changes added to commit (use 'git add' and/or 'git commit -a') Now you pull and someone has introduced a new setting there, creating a conflict. Possibly because your local changes are just debug: true in some settings file. Suppose you have this scenario where you stash your changes in order to pull from origin. It usually solves all or the majority of conflicts automatically itself. KDiff3, Meld, etc., instead of doing it manually. I highly recommend using any of 3-way merge tools for resolving conflicts, e.g. If you don't like it, you can always use git restore -staged. This way you can differentiate the changes from the previous stash and changes you made after the conflict was resolved. marks the conflicts as resolved and removes files from the index, git add also marks the conflicts as resolved, but keeps files in the index.Īdding files to the index after a conflict is resolved is on purpose. There are two ways of marking conflicts as resolved: git add and git restore -staged. Translated to the command-line commands: $ git stash pop Finally, remove the stash with git stash drop, because Git doesn't do that automatically on conflict.You don't have to execute git add before. If you want to unstage only specific files, use the command git restore -staged instead. to mark conflict(s) as resolved and unstage all files in the staging area. Manually (or ideally using some merge tool, see below) resolve the conflict(s).So let's do what Git suggests ( without making and reverting any pointless commits): If you want to learn about the differences between those commands, check the documentation. Currently, any of those commands may be used and the outcome is the same. (the dot is necessary and it specifies any file). Restore command's equivalent is git restore -staged. You could also use git reset to unstage any and all files in the staging area (called the index). Older versions of Git suggested to use the command git reset HEAD. Note: The restore command has been introduced in Git version 2.23.0. The following solution seems to be much cleaner to me and it's also suggested by the Git itself - try to execute git status in the repository with a conflict: Unmerged paths: 🙂 But I don't think that doing a commit and then resetting the branch to remove the commit you just created and similar workarounds suggested in other answers is the clean way to solve this issue.

Git stash files