On Thu, Mar 17, 2011 at 07:48:54PM +0100, Alex Riesen wrote:
> 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
--
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