Re: Cherry picking instead of merges.

["Avery Pennarun" <apenwarr@gmail.com>]

On 7/3/08, David Brown <git@davidb.org> 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