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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html