On 03/17/2011 07:38 AM, Jeff King wrote:
> On Thu, Mar 17, 2011 at 01:21:19AM -0400, Jay Soffian wrote:
>
>>> Git doesn't support distribution of a merge (although that would be
>>> extraordinarily cool), so the next best thing seemed to be force adding all
>>> files with conflict markers and then committing the merge. We then publish
>>> the conflicting branch and have each person fix their files. Given that the
>>> conflict markers are already in place, they can't use their favorite
>>> graphical merge tool.
>>
>> Well, this is awful, but you could do something like:
>>
>> for x in conflicted_files:
>> git show :1:$x > $x.base
>> git show :3:$x > $x.theirs
>> git checkout --ours $x
>> git add $x.base $x.theirs $x
>>
>> Commit that, then folks can use their favorite merge tools, commit the
>> result, and remove the .base and .theirs.
>
> I don't think you need to do anything so drastic. You can just have
> everybody do the partial merge, commit, and then push their result. And
> then as you suggest below, one person does the real merge, uses checkout
> to install the desired result state from each person's partial tree, and
> then everybody throws away their partial merges.
>
> The trick is that each person will resolve some conflicts and commit,
> but you need to know which ones they resolved. They can't leave things
> unmerged in the final commit. So they would have to provide such a list
> to you; one way is in the commit message[1].
>
> So let's say you have three devs, Alice, Bob, and Charlie, and one
> integrator, Matt, who will do the merge. Each of the developers does:
>
> git checkout -b partial-merge
> git merge old-topic
> git mergetool ;# or manually resolve and git add
>
> Eventually they get tired of the conflicts and give up. So they record
> the list of resolved paths, either manually or with something like[2]:
>
> {
> echo 'partial merge result'
> echo
>
> git status --porcelain | perl -ne '
> next if /^U|\?/;
> s/^\S+\s+//;
> print;
> '
>
> } >msg
>
> And then they stage the rest of it (knowing it will be ignored by Matt)
> and commit:
>
> git add -u
> git commit -F msg
> git push wherever partial-merge
>
> Then Matt does the actual merge:
>
> git merge old-topic
>
> which of course results in lots of conflicts. So he pulls resolved
> versions from each person's tree:
>
> for i in alice bob charlie; do
> git fetch $i
> git checkout $i/partial-merge -- \
> `git log -1 --format:%b $i/partial-merge`
> done
>
> And then fixes up whatever's left manually or with git-mergetool, and
> commits the end result.
>
> Take all of my scripting there as illustrative of the concept, but not
> necessarily a good idea. In particular, it doesn't handle quoting of
> filenames at all, and it probably doesn't handle files whose resolution
> was to be deleted (since the checkout will fail).
This discussion is great! Is there some place where this sort of a thing
usually ends up, such as a wiki or the Git Community Book
<http://book.git-scm.com/>?
Cheers,
--
Victor Engmark
--
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