Re: re-running merge on a single file

Chris Packham [off-list ref] writes:

... I'm lazy and my
projects rules allow broken commits so ...

We cannot fix, nor it is our job to fix, lazy people or undisciplined
projects ;-)

Having said that you can still retry your merge, which was _mostly_ Ok.

 (1) First, check out the original commit before the merge.  You may have
     built a few more commits on top of it, so "git log --first-parent"
     may help to find that commit.  Suppose you found that merge commit
     and we call that $merge; then:

     $ git checkout $merge^1
   
 (2) Then you retry that merge:

     $ git merge $merge^2

     which would conflict the same way you saw.

 (3) If you have rerere enabled, then the conflicts would be already
     resolved in your working tree at this point, but not in the index, so
     you can reproduce the conflicted state with "checkout -m".

 (4) If you didn't have rerere enabled, then you would have a lot of
     conflicted files in the working tree.  Inspect them by comparing with
     $merge:

     $ git diff $merge

     Since we are assuming that most of the resolution was good, and you
     know what paths you want to fix your earlier resolution for, you
     would want to take what is in $merge for most of the paths.  You can
     run checkout on paths that you know were good in $merge, like so:

     $ git checkout $merge -- include/ drivers/

     and repeat this step to narrow it down to the paths you are
     interested in.

 (5) After you fix the resolution and make a commit,

     $ git diff $merge

     will show that your earlier incorrect resolution is replaced by a new
     correct resolution.

After that, you can rebase your branch on top of HEAD to conclude.

Note that recent git can use "checkout -m path" to reproduce conflicts
even after you ran "git add path".