On Thu, 3 Jul 2008, David Brown wrote: > > First we tried a git-merge and resolved the conflicts. The problem here is > that the resultant code didn't work. git-bisect wasn't very useful because > the intermediate versions don't have resolved conflicts. > > Yesterday, one developer cherry picked company B's changes into a branch. > It appears he resolved the conflicts for each commit, which should make > bisecting easier. What I would suggest is actually a stupid combination of the two. The advantage and disadvantage of the cherry-picking is: - the cherry-picking obviously gave you the end result you wanted, and is bisectable at a per-commit level (ie each cherry-pick was a "micro-merge", and if there was a merge problem, it would show up exactly in _that_ one) BUT - the cherry-picking doesn't help future merges, since the history is disjoint, and as such it will always diverge and just cause more and more problems down the road to keep on doing this. so what I would suggest is - generate the *state* of the tree by cherry-picking each commit one by one, and verify that state. - but then do a merge that picks that one state as the merge result (this is all assuming you cherry-picked every single commit, of course!) The latter thing is really easy to do. Just do the merge, and ignore the conflicts that happen entirely, because you then just use the tree from the temporary cherry-picking branch # Try to merge the other branch .. git merge otherbranch # .. but ignore conflicts entirely by then # setting the index and checked-out state to # the known-good end result git read-tree -u --reset cherry-picked-branch # .. and commit that instead git commit # and you can now remove the cherry-picked branch # that was only used for the tree git branch -D cherry-picked-branch to actually commit that merge and get rid of the temporary cherry-picking branch. (Of course, if the merge actually doesn't generate any conflicts, and thus commits it, but doesn't actually _work_, then that "git commit" needs to be a "git commit --amend" instead, in order to actually replace the merge commit rather than add a fixup commit afterwards) End result: you have a nice merge with nice history that actually converges at a common point, but you effectively did the merge resolution one commit at a time with cherry-picking (or "git rebase", which is obviously just a convenient shorthand for cherry-picking everything). This actually has a few other advantages too: "git show --cc" on that merge will also show the conflicts the way they got resolved, so you actually end up with some useful information this way too. Linus -- 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
