Re: [PATCH] merge_blobs: use strbuf instead of manually-sized mmfile_t

["Stefan Frühwirth" <stefan.fruehwirth@uni-graz.at>]

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