Chris Packham <judge.packham@xxxxxxxxx> 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".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html