Re: Help breaking up a large merge.

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Sep 18, 2008, 16:41 UTC
Message-ID: <48D284BE.5040107@viscovery.net>
In-Reply-To: <20080918152154.GA27019@linode.davidb.org>

David Brown schrieb:

Show 14 quoted lines

> Say we have a tree that we've been working on for a few months.  An
> outside vendor has also been working on the same tree during this
> time, and we need to merge with their work.
> 
> The difficulty I'm having is that there are a lot of conflicts
> resulting from the merge (expected), and it would be nice to somehow
> be able to work on a smaller set of these conflicts at a time.
> 
> Some of the conflicts are caused by a single change in the other tree.
> This is easy to cherry-pick into my tree, resolve, and then test those
> changes independently.
> 
> But other conflicts are caused by groups of commits that are
> interleaved with others.

In a similar situation I was thinking about this approach:

1. Do the merge.
2. Resolve conflicts in an area that can be tested in isolation.
3. Undo all other changes that the merge brought in.
4. Commit.
5. Install a graft that removes the second parent of the merge commit.
6. Rinse and repeat.
7. Finally, remove the grafts, and perhaps collapse the merge commits.

I didn't test this, yet.

Hmm, thinking a bit more about this, 1 and 5 can probably be replaced by a mere 'git merge --squash'.

-- Hannes