Re: git and larger trees, not so fast?

Junio C Hamano [off-list ref] writes:

While I do not think the previous one was hacky at all, this one
IS a hack, not meant for inclusion.  It makes the partial commit
codepath to use vanilla "git read-tree" without any single tree
merge semantics, and rewrite that codepath to use read_tree()
which was changed with my previous patch.

Just in case anybody is wondering, this also passed all the
existing tests.  Maybe it is going in the right direction of
slowly moving away from unpack_trees() where we can.  I dunno.

I also do not know if it "fixes" the performance issue on that
testcase.