Cumulative "git read-tree -m" rejected with overwriting warning

Hello,

Consider the following use case:

git init
seq 0 9 > f
git add f
git commit -m start

git checkout -b b1
perl -pi -e 's,0,b1,' f
git commit -a -m b1

git checkout -b b2
perl -pi -e 's,9,b2,' f
git commit -a -m b2

git checkout master
git merge b1 b1

As the changes to "f" don't conflict, the octopus merge deals with them just fine, and I get a merge in a single commit object.

Now, let's say my b1 and b2 branches are a bit more special, and apart from the main contents (i.e. the "f" file), each branch contains a couple of files with branch-specific metadata. The names of those files are the same in each branch. (People familiar with topgit can probably guess I'm talking about topgit branches here.)

I'd like to merge all such branches into "master" in one octopus-like commit, but the metadata files introduce a conflict during simple octopus merge. However I don't care about that metadata when the branches are merged into "master", so I'm trying to write a script which would do such merge while discarding the metadata files.

The problem is, I cannot get it to work, when two branches modify the same file (like "f" above), even if the changes don't conflict. I get either:

error: Entry 'f' would be overwritten by merge. Cannot merge.
- when trying to use the two-arg form of "git read-tree -m -i"

or:
f: needs merge
- when trying to use the three-arg form

Attached is the minimal test case that reproduces the problem.

It might just be that git-read-tree cannot do what I need, and I'm just misinterpreting the meaning of:

"the index file saves and restores with all this information, so you can merge things incrementally,"

which I took to mean that I can read from multiple trees one by one before writing the tree.

Could anyone give me some hints?

Marcin Owsiany <[email protected]>              http://marcin.owsiany.pl/
GnuPG: 2048R/02F946FC  35E9 1344 9F77 5F43 13DD  6423 DBF4 80C6 02F9 46FC

"Every program in development at MIT expands until it can read mail."
                                                              -- Unknown

That "incrementally" refers to "after a three-way merge stops with conflicts in multiple files, you can start from file A, concentrate only on that file, resolve it, and then go on to resolve conflicts in the next file B, continue, until you resolve the conflicts in the last file Z". Until you resolve a single tree-way merge fully and write the results out as a tree, you cannot merge in the next tree.

That is why N-way octopus is internally implemented as a series of three-way merges.