`git stash` during a merge conflict

Question

We\'ve done something bad.

We ran git stash save during a merge conflict, and now we can\'t restore our work.

Things we\'ve tried:

g         


        

Answer 1

I did the same thing today, and took a different approach (after trial and error) to get back to the state just prior to stashing so I could continue resolving conflicts and complete the merge.

First, after unstashing the partial merge in the destination branch, I captured a list of the files with remaining conflicts (text file or editor tab). This is just the list of unstaged files after unstashing, as the files with conflicts already resolved would have been staged prior to stashing.

$ git status
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   myproject/src/main/java/com/acme/package3/Class3.java
#   modified:   myproject/src/main/java/com/acme/package3/Class4.java
#

Next, I created a patch and reset the branch back to the pre-merge state:

$ git diff HEAD > ~/merge-with-resolved-conflicts.patch
$ git reset --hard HEAD

Then I created a temporary branch (derived from the merge destination branch), and applied the patch:

$ git checkout -b my-temp-branch
$ git apply ~/merge-with-resolved-conflicts.patch
$ git commit -a -m "Merge with resolved conflicts"

So the HEAD of my-temp-branch now contains everything that was merged, including files with conflicts resolved, and files with remaining conflicts.

Then I switched back to original branch, merged again, and looked at the git status

$ git checkout my-branch
$ git merge other-branch
$ git status

The status shows the full list of files with conflicts:

# Unmerged paths:
#   (use "git add <file>..." to mark resolution)
#
#   both modified:      myproject/src/main/java/com/acme/package1/Class1.java
#   both modified:      myproject/src/main/java/com/acme/package2/Class2.java
#   both modified:      myproject/src/main/java/com/acme/package3/Class3.java
#   both modified:      myproject/src/main/java/com/acme/package3/Class4.java
#

Now I needed to compare these two lists of files. Any files in the second list but not the first had already been resolved (in this example, Class1.java and Class2.java). So for each of those files, I pulled in the version with conflicts resolved from the temporary branch (like cherry-pick, but for individual files rather than an entire commit):

$ git checkout my-temp-branch myproject/src/main/java/com/acme/package1/Class1.java
$ git checkout my-temp-branch myproject/src/main/java/com/acme/package2/Class2.java

Having done this, I was back to the state before the stash, so I could resume resolving the remaining conflicts and commit the merge.

Answer 2

My solution to get out of this (git stash pop during a merge conflict) was:

• create and checkout a new (local) branch mytemporarybranch

  git branch mytemporarybranch && git checkout mytemporarybranch

• commit into this mytemporarybranch

  git commit -m "my messy merge and squash"

• checkout myoriginalbranch

  git checkout myoriginalbranch

• merge correctly (no squash pop/apply this time!)

• squash merge the mytemporarybranch onto the myoriginal branch

  git merge --squash mytemporarybranch

Answer 3

Given your last comment : you can use

git stash megre --no-commit <branch>

to put the index in a "merge" state without committing the changes

then modify it with what you want :

if you have already worked out your merge in the stash :

git reset #to remove the "conflicts" flags
git checkout <initial commit> -- ./ #to revert everything to the previous working state,
git stash apply   #apply your changes

and once everything is in the desired state, git commit

---

About bukzor's comment : there is actually a big difference between git checkout <tree-ish> and git checkout <tree-ish> -- <files>.

From the reference on git checkout :

• git checkout <branch> : This form switches branches by updating the index, working tree, and HEAD to reflect the specified branch or commit.

• git checkout [-p|--patch] <tree-ish> -- <pathspec> : When <paths> or --patch are given, git checkout does not switch branches. It updates the named paths in the working tree from the index file or from a named <tree-ish> (most often a commit).

git checkout <initial commit> would indeed discard the merge informations.

git checkout <initial commit> -- ./ (note the extra -- ./), on the other hand, will keep the merge information, and revert every tracked file to its state in <initial commit>.

Answer 4

The issue seems to be that git stash doesn't save a reference to the branch you were trying to merge in. During a merge, this is stored in a ref named MERGE_HEAD.

To fix it and get back to your previous state, you need to find the revision (let's pretend it's d7a9884a380f81b2fbf002442ee9c9eaf34ff68d) you were trying to merge in, and set MERGE_HEAD to it after you apply the stash.

Then you can apply the stash (with --index to re-stage everything that was staged before), and set your MERGE_HEAD:

git stash apply --index
git update-ref MERGE_HEAD d7a9884a380f81b2fbf002442ee9c9eaf34ff68d

Answer 5

When you are in a conflicted state ( index and working directory), you will not be able to do git stash - it will give an error sating unmerged entries.

Make sure that you have really done a stash. See output of git stauts and git stash show