* question about conflict resolution across multiple branches
@ 2009-03-19 17:56 William Morgan
2009-03-19 20:11 ` Junio C Hamano
0 siblings, 1 reply; 3+ messages in thread
From: William Morgan @ 2009-03-19 17:56 UTC (permalink / raw)
To: Git Mailing List
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 <wmorgan-git@masanjin.net>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: question about conflict resolution across multiple branches
2009-03-19 17:56 question about conflict resolution across multiple branches William Morgan
@ 2009-03-19 20:11 ` Junio C Hamano
2009-03-22 20:05 ` William Morgan
0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2009-03-19 20:11 UTC (permalink / raw)
To: William Morgan; +Cc: Git Mailing List
William Morgan <wmorgan-git@masanjin.net> 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: question about conflict resolution across multiple branches
2009-03-19 20:11 ` Junio C Hamano
@ 2009-03-22 20:05 ` William Morgan
0 siblings, 0 replies; 3+ messages in thread
From: William Morgan @ 2009-03-22 20:05 UTC (permalink / raw)
To: Git Mailing List
Reformatted excerpts from Junio C Hamano's message of 2009-03-19:
> $ git diff origin/next >fixup.patch
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?)
> Needless to say, you need to be careful when accepting such a fixup
> patch.
More careful than when accepting a "regular" patch?
Thanks for your help!
--
William <wmorgan-git@masanjin.net>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-03-22 20:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-19 17:56 question about conflict resolution across multiple branches William Morgan
2009-03-19 20:11 ` Junio C Hamano
2009-03-22 20:05 ` William Morgan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).