William Morgan <wmorgan-git@xxxxxxxxxxxx> writes:
> 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.
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 ;-).
> ... 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?
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).
> 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?
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.
--
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
