How to incrementally merge large branches with Git?

Question

Overview:

We have a fairly large (~10M LOC) repository that we want to handle with Git. We need to do complicated merges between development branches that are too big to do in one shot. However, it appears Git does not support this. After you commit a "merge" between two branches, Git assumes all the files on those branches have been addressed. What is the best workflow to incrementally work on a huge merge?

Background:

We want to distribute the work over several commits and several developers. The code base is being actively updated by different teams via independent CVS repos. So the work on their branches are just tarball code drops with no commit history between drops.

Our plan was to store the drops on different branches like this:

Master : Rel 1 -> Rel 2

Site B : \ -> Rel 1.1

Our team is intended to do work similar to Site B, but Site B may continue to work in parallel. So we will keep the "Master" and "Site B" branches untouched for future imports. We will create a new development branch for our work. The first step being merging the difference between "Rel 1" and "Rel 2" onto the Rel 1.1 work. Essentially a 3-way merge between the "Master" and "Site B" branches.

Doing individual merge-file operations seems clunky and doesn't preserve any actual history. Similar with doing cherry-picks.

Any advice?

Answer 1

This is an old question, but since it just came up for me from a related google search and doesn't have an answer, I'm answering it now.

The git imerge tool handles the problem by supporting incremental, collaborative merges. The imerge docs point to a great blog post about how to use it.