Where do all the tips go? (Was: Re: Sharing a massive distributed merge)

On 03/17/2011 07:38 AM, Jeff King wrote:

On Thu, Mar 17, 2011 at 01:21:19AM -0400, Jay Soffian wrote:

quoted

quoted

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

On Thu, Mar 17, 2011 at 08:51:58AM +0100, Victor Engmark wrote:

quoted

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/>?

There's an FAQ section on the wiki:

  https://git.wiki.kernel.org/index.php/GitFaq

though I am not sure this is frequently asked. The Git Community Book
seems pretty inactive these days. The last work on it is about 2 years
old:

  https://github.com/schacon/gitbook

These days Pro Git is freely available and seems much more active:

  https://github.com/progit/progit

I know Scott is collecting random advanced topics like this for an
eventual second edition. Maybe this topic would be of interest.

-Peff