On 2016-02-16 at 21:35 Jeff King wrote:
Yeah, I agree there isn't a great solution in git here. Using "git
merge" is definitely wrong if you don't want to touch HEAD or have a
working directory. If you _just_ care about doing the tree-level merge
without content-level merging inside blobs, you can do it in the index
like:
export GIT_INDEX_FILE=temp.index
base=$(git merge-base $ours $theirs)
git read-tree -i -m --aggressive $base $ours $theirs
If you want to do content-level resolving on top of that, you can do it
with:
git merge-index git-merge-one-file -a
though it will need a temp directory to write out conflicts and
resolved content.
That's an interesting alternative, I'll give it a try!
I don't think merge-tree is at all the wrong tool, in the sense that it
is being used as designed. But it is using merge code that is different
from literally the rest of git. That means you're going to run into
weird bugs (like this one), and places where it does not behave the
same. This add/add case, for instance, is usually a conflict in a
normal git merge (try your test case with "git merge"), but merge-tree
tries to do a partial content merge with a base that never actually
existed[1].
Thank you for clarifying, I understand.
So I worry that merge-tree's existence is a disservice to people like
Chris, because there is no disclaimer that it is effectively
unmaintained.
I agree, I don't want to advocate continuing development under these
conditions.
So merge-blobs.c:generate_common_file() is definitely buggy, but I think
the bug gets unintentionally canceled out by the follow-on three-way
merge. Which is...good, I guess?
Well I don't know how to handle all this with respect to my original
problem, but that's completely off topic. Anyway: Thanks!
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
