views:

67

answers:

2

Hi,

I want to merge to very diverged Git branches together. That will be a lot of work because they have several hundreds conflicts.

What would be the best way, so that maybe also others can help me and also work on this merge?

Normally, I am doing just the 'git merge ...' and then going through all conflicts, resolving them, then do the commit. But that is local only then.

The work on the conflict-resolving maybe can take several days. I want to put my changes online already while I am working on it.

A: 

Hi, if you want others to help you, you need to put those branches on some accessible server as remote branches.

You don't have to do all the work at once. Branches diverged on some point in time. So you start working from there but merging commits gradually.

For example you have master branch and very different branch called b.

if you switch to master and do git merge b you will get ton of conflicts.

So you start looking in history where master and b separated. Then take for example third commit in b branch and merge it

git merge <sha_in_b_branch>

You will get you only a few conflicts. Resolve them, commit, push your changes to remote branch and then somebody else can continue. Takes next few commits, resolve conflicts, commit push etc. Continue like that until you come to head of b branch.

Rubycut
I will probably get as many conflicts when I merge the third commit in b as when I merge the top of b to current master (because master has changed so much). And wouldn't I have to resolv the same conflicts again and again?
Albert
Yes, total number of conflicts will be the same if merging everything at once and merging gradually. But you can't avoid that since you allowed branches to diverge.Your initial question is how other can help you resolving conflicts and how your work can be online and I gave you answer.You will not need to resolve conflicts over and over again. Just once. But gradually.repos and branches are cheap. So you can make test repo, create two branches and diverge them, then try to merge them. That is what I did.
Rubycut
+1  A: 

When facing this problem recently, I decided to rewind the diverged to-be-merged branch to the last common commit (which I found out with git cherry -v upstreambranch divergedbranch) and to remove all commits, that I didn't want to merge. (I. e. those commits already present in the master branch, if with a different hash.)

So from the list of commits in

git rebase -i --onto lastcommoncommit upstreambranch divergedbranch

I removed all commits that were listed in

git log lastcommoncommit..upstreambranch

The outcome of this is a clean but slightly outdated topic branch containing only commits that aren't already part of upstreambranch.

From this point on there are mainly two ways to proceed:

  1. You could git cherry-pick commits from the outdatedbutcleantopicbranch into upstreambranch's HEAD, starting with the oldest unmerged commit.
  2. Rebase the outdatedbutcleantopicbranch to older states of upstreambranch like git rebase --onto upstreambranch@{4 weeks ago} upstreambranch

After finishing a rebase/cherry-pick session you push your changes to an integration branch where someone else can continue using the same process.

al