Re: Sharing a massive distributed merge

From: Jeff King <peff@peff.net>
Date: Mar 17, 2011, 19:15 UTC
Message-ID: <20110317191517.GC20508@sigill.intra.peff.net>
In-Reply-To: <AANLkTi=Fnacc9JamGdOEYhHY8PJgaidSLmif_z5Qdfp0@mail.gmail.com>

On Thu, Mar 17, 2011 at 07:48:54PM +0100, Alex Riesen wrote:

Show 5 quoted lines

> How about not to record the merge as a merge commit, but
> just resolve as much as possible, commit _only_ what was
> resolved, and revert everything else. Including files merged
> cleanly, as the last merge by maintainer will have to clean
> merge them anyway. And of course, commit as normal:

But that still has the same problem. You've reverted unresolved files back to the pre-merge state, which is the tip of one of the merged branches. How does the integrator differentiate that from the case that your resolution happened to take one side of a file?

For example, try this:

    git init repo && cd repo

    echo base >file1
    echo base >file2
    git add .
    git commit -m base

    echo master >>file1
    echo master >>file2
    git commit -a -m master

    git checkout -b topic HEAD^
    echo topic >>file1
    echo topic >>file2
    git commit -a -m topic

    git merge master

    # now we have a conflict. Both files are identically conflicted.
    # Let's resolve one in favor of topic.
    cat >file1 <<'EOF'
    base
    topic
    EOF
    git add file1

    # Now let's mark the other as unresolved. The proposal is to revert
    # it back to the pre-merge state.
    git checkout HEAD -- file2

    # And commit the partial result.
    git commit -m 'partial result'

It should be easy to see that the two cases are indistinguishable: both files contain the exact same content in the reuslting partial result (and obviously the fact that they are identical is contrived, but the point is that for any given file, you don't know which thing happened during the partial merge).

Which is why I suggested deletion as an option, but that also conflicts with a possible resolution (it's just a less likely one). I think every tree state that you could commit to mark "this isn't resolved" is going to overlap with some possible actual resolution state. So you need an external list.

It would be neat if the tree could somehow mark a bit for "this is unresolved". I guess we could shove it into a mode bit. But that seems like a waste of a mode bit for this one use case that doesn't come up all that often, and which doesn't _need_ to represent that information in-tree. The commit-message solution would work perfectly fine.

-Peff