On Fri, Mar 12, 2010 at 3:07 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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 ;-) Fair call. I don't think the maintainers of human-nature-v1.0 are interested in patches :) Actually on another note wasn't there an idea of being able to say that a particular set of commits is known to break bisect-ability? Ideally I'd want one commit that comprises the merge from upstream, at this point the build targets from upstream should build happily but the targets we've added we know are broken. Then I come along and fix the targets we've added, maybe doing commits sub system by sub system to make review easy. Finally whatever work is left to actually make our targets build successfully is in another commit. From a bisect point of view I'd want to say that the merge and sub system commits are intentional breakages and that bisect should really look at this whole series as a single uber commit. I guess this is information that could go into notes that bisect could then take into account when making its next jump. > 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". Mental note: Need to learn more about git rerere. Sounds like what I need to do the job. > (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". OK I'll look out for that in future. This won't be the last time I'm doing a big merge. -- 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