question about conflict resolution across multiple branches

Hi all,

I have a git usage question about topic branches and conflicts.

I maintain a project that I believe follows the standard topic branch model. It has two "version" branches, master and next. When a new feature is introduced, I create a topic branch off of master, commit, and merge the topic into next. Users can check out next to play with all the latest goodies. If a topic branch has problems, I add bugfix commits to it, and re-merge into next. Once it seems stable, I merge it into master. (Branching topic branches from master is necessary in order to be able to merge them into master without pulling everything else that's in next.)

So this is nice, because I can pick and choose which features to have in master, more or less independently of each other. The one thing I haven't been able to figure out is this:

Sometimes those topic branches are remote branches on someone else's repo. What happens when merging a remote topic branch into next creates a conflict? Ideally I'd like for the topic branch author to deal with resolving the conflict, and leave me to my carefree maintainer existence of eating icecream on the couch. In the no-conflict case, I merge their remote branch directly into my local next. But in the case of conflicts, it seems like me only way to acquire their resolution is to merge their next branch entirely into mine. Is that true?

Likewise, what happens when someone sends a patch against master to the mailing list, and applying that patch to next creates a conflict? Is there any way for them to resolve the conflict, and pass that resolution to me?

Thanks for any help.

William Morgan <wmorgan-git@masanjin.net> writes:

Well, merging, applying and managing the conflicts between contributors is what the maintainers do. If you push that to your contributors, you do not have to exist ;-).

It is not clear what you mean by 'their next' as the only thing you told us is "some topic are from elsewhere". Do you mean the originator of the topic also keeps an integration branch of his own, something similar to your 'next'?

If that is the case, I _think_ you can fetch their next and feed the merge you are interested in to rerere-train.sh (in contrib) before you attempt the merge yourself. This is "I _think_" because I never used that script myself (and it wasn't even accepted to git.git by me---I was away back then).

You can tell the contributor that the area the patch touches is under an active development that you expect to be ready soon, and ask him to redo the patch on a specific commit on the topic.

Or you can ask the contributor to do this:

    $ git fetch ;# from you
    $ git checkout origin/master ;# detach to your master
    $ git am the-patch
    $ git merge origin/next ;# this will conflict you cannot resolve
    $ edit to resolve conflicts
    $ git commit ;# the resolution you cannot come up with yourself
    $ git diff origin/next >fixup.patch

and send the fixup.patch to you.  You would do the reverse:

    $ git checkout master
    $ git am the-patch
    $ git checkout next
    $ git merge -s ours master
    $ git apply --index fixup.patch
    $ git commit --amend
    $ git show ;# to review what the fix-up did

Needless to say, you need to be careful when accepting such a fixup patch.

Reformatted excerpts from Junio C Hamano's message of 2009-03-19:

Ok, this is helpful. So git diff will give me an explicit dump of the conflict resolution changes, which I can use with git apply --index when I see the conflict. Sort of a manual, shared, git-rerere.

Wouldn't it be simpler for git format-patch to produce something for a merge commit with conflicts? (Maybe there's a way and I just can't find it?)

More careful than when accepting a "regular" patch?

Thanks for your help!