On Fri, Jul 04, 2008 at 02:10:03AM +0200, Björn Steinbrink wrote:
The other one is merging: A---B---C---M \ / D---E---/ Of course, you should end up with the same tree either way. It's just a different way of getting towards that final state. So commit E' and commit M, while different commits, would point to the same tree object.
Ok. I guess I need to explain a little further. The advice I've gotten is good, BTW. After we've resolved the merge and committed it, we've then discovered that it doesn't work. However, there are around 100 commits on both branches of the merges and it would be nice to come up with some way of doing something like a bisect. The trick is that the branch being merged in doesn't actually work on our platform, so I can't just test the alternate branch. But, git-bisect isn't being all that helpful here. The problem is that the only conflicts we resolved is how the two trees were put together. Picking points in the middle seem to generate lots of similar, but not quite the same conflicts. A cherry-picked tree would allow for an easy bisect, since all of the intermediary versions would work. If I somehow knew magical points within the other tree I could do some number of merges and the bisect would still work. I suppose I could do the merges one at a time, but it would make the history rather verbose. Thanks, David -- 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
