maildir / read-tree trivial merging getting in the way?

I've spent a few hours playing round with maildir-aware merging.

The basic idea I'm trying to implement is to flip the index round so that 
instead of looking at how the content has changed for a particular filename, 
I'm looking at how the filenames have changed for a particular content.

So I'm using git read-tree -m to populate the index with entries for the 
branches to merge so that I can then diddle round with those.

But the read-tree trivial merge logic seems to be getting in the way a bit.

In my test repo, I have two branches ('master' and 'red') forked from the base 
point 'base':

in 'base':

$ ls
A    fish one

in 'red':

$ ls
B         billygoat one

in 'master'

$ ls
A    lion two

From base, I renamed and cg add / cg rm'd to change A to B, one to two, 

and fish to billygoat and lion to give the above.

When I read in the tree I get automatic resolving (down to stage 0) for the 
added files. But actually in the output of my merge, I'm not always going to 
want that to happen: In the A->B case, I do want to keep B (and need to remove 
A), likewise in the one->two case.

But for fish->{billygoat,lion}, I only want one file to end up at stage 0, and 
it might not be called either billygoat or lion - in maildir, the filenames are 
more structured, and given a filename like
foo:2,SR and foo:2,SF I would want to compose the filenames to give me 
foo:2,SRF.


$ git read-tree -m base master red

$ git ls-files  --stage
100644 40e0a6f540b1b457c61315f3ccf2f5ed628e2f36 1       A
100644 40e0a6f540b1b457c61315f3ccf2f5ed628e2f36 2       A
100644 40e0a6f540b1b457c61315f3ccf2f5ed628e2f36 0       B
100644 a8150e61a3a4c9941d29169ee639396547f40de2 0       billygoat
100644 a8150e61a3a4c9941d29169ee639396547f40de2 1       fish
100644 a8150e61a3a4c9941d29169ee639396547f40de2 0       lion
100644 b67e17aeb5938def7ee105c2afe9fbb30a28a872 1       one
100644 b67e17aeb5938def7ee105c2afe9fbb30a28a872 3       one
100644 b67e17aeb5938def7ee105c2afe9fbb30a28a872 0       two

Now, I think maybe I can just look at what has made it to stage 0 and play 
round with those, but it makes me feel a little dirty - if anything, the index 
indicates that a bunch of stuff has been correctly merged (by being at stage 0) 
when in fact it hasn't.

So basically my question is: should I feel dirty about doing this and diddle 
read-tree so that there's a flag to not do the trivial merges automatically?

--