On Tue, Jul 14, 2009 at 7:32 PM, <davidb@xxxxxxxxxxx> wrote: > I'm trying to figure out a better way of dividing up the effort > involved in a merge amongst a group of people. Right now, I > basically describe the merge to each of them, and ask them to > merge their part, and then 'git checkout HEAD' the other parts. > They tell me about the commits, along with the files that they've > merged correctly. When everybody is done, I make a real merge > commit, and pull in all of their files. It's a lot for me to > track, and confusing for each person. What do you mean by describing a merge? git is designed to have all the information needed for a merge inherent in the repository history. > I'd like to create a branch we can all push to that we gradually > work to become the result of a resolved merge. Not only does git > not want to help me do the merge, but seems to actively be > fighting against me doing this. > > What I thought of was something like telling people to do: > > $ git merge v2.6.30 > resolve some files > $ git checkout HEAD ...rest of files... > $ git commit; git push > > but that 'rest of files' is fairly large and complicated. I can > think of two ideas: > > - Something that basically does a partial 'git reset --hard > HEAD' to put many of the files back. > > - The ability to specify subpaths on the 'git merge' to do the > merge work but limited to a directory or set of files. > > Obviously, either case will require someone to still track the > overall effort and make sure the final state of the tree really > represents the total merge. > > Is there anything that can parse the output of 'git merge-tree'? > Even just splitting this up and then applying parts of it would > be helpful. Would it be useful to write something that can apply > the results output of 'git merge-tree'? I'm having a hard time understanding the situation here - why can't you just: $ git checkout -b mergebranch v2.6.30 $ git merge developer1/topic # Fix conflicts $ git merge developer2/topic # Fix conflicts # etc Why are there so many conflicts to make this an issue? If the commits are isolated to small changes, rebasing the developer topic branches instead of merging may help, by allowing you to take conflicts one commit at a time. For example, if your problems are primarily conflicts between developer branches and upstream: $ git checkout -b mergebranch-dev1 developer1/topic $ git rebase v2.6.30 # Fix conflicts on a commit-by-commit basis $ git checkout -b mergebranch-dev2 developer2/topic $ git rebase v2.6.30 # Fix conflicts on a commit-by-commit basis $ git checkout -b mergebranch $ git merge mergebranch-dev1 # Fix any remaining conflicts If your problems are because of conflicts between developer branches and each other: $ git checkout -b mergebranch-dev1 developer1/topic $ git rebase v2.6.30 # Fix conflicts on a commit-by-commit basis $ git checkout -b mergebranch-dev2 developer2/topic $ git rebase mergebranch-dev1 # Fix conflicts on a commit-by-commit basis These rebasing approaches will change the commit IDs, so your developers will need to rebase any further work upon these new commit IDs, but if things are as bad as you say, a commit-by-commit merge that rebase allows you may be much simpler. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html