On 7/3/08, David Brown <git@xxxxxxxxxx> 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. > > The problem is that we now have very divergent history. > > Any advice on how to make use of how he resolved conflicts in order to > merge company B's changes in using git-merge. [...] Unfortunately, since your mismerged branches are already published, rewriting history would cause a lot of pain for everyone. It would be better to avoid doing that entirely. However, I can see why you'd want to do that in order to make future git-bisect easier. Basically, if you're going to try to fix the git-bisect intermediate versions, you're going to have to rewrite history anyway; in which case, why not just make your developer's cherry-picked branch the official one? Then your problems are solved, other than getting all your developers onto the new history. Alternatively, if you just want to fix your main development tree so that it's "correct", then you could do this: - Go to a point in time where both branches (main and developer) have exactly the same set of patches: that is, your company + company B. The exact history (ie. commit ids) will look different, because the two branches took different paths to get there, but the code *should* have been identical at those two times, since you have the same set of patches. Call the two points X and Y. - X (on the main branch) is actually different from Y (on your developer's branch) because someone mis-resolved the conflicts on X. However, the only difference between X and Y should be the mis-merge. Thus: - git diff X..Y >fix-mis-merge.patch - git checkout HEAD - git apply fix-mis-merge.patch This will apply the correct conflict resolution to the tip of your newest branch. All the revisions between X and HEAD will still be broken, but that's usually better than trying to rewrite history and pretend the broken revisions never existed. You can always use "git bisect skip" for cases like that. Have fun, Avery -- 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
