Re: Cherry picking instead of merges.

[David Brown <git@davidb.org>]

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