git-merge-cache / StGIT - gitmergeonefile.py: merging one tree into another rather than two trees into merge base

(Please CC me on replies as I'm not subscribed).

I experienced a (performance) problem with StGit, but I don't know if it's the culprit or if git-merge-cache is.

Today I was pushing my patch stack (which was against Linux 2.6.13) on top of the latest snapshot I have (i.e. upstream will likely have some mega of patches). And it was *really* slow (say it pushed 8 patches in 5 minutes).

After the analisys, it's more or less logical - it'd take more or less the same time to merge upstream changes against local ones. The problem is that it's not how things should go.

I looked with "top" at what was happening, and I saw a lot of time spent by either gitmergeonefile.py or git-update-cache --remove*. And looking at the merge algorithm, I realized it merges both HEAD and patch top into the patch bottom (or something like that).

I.e. if upstream rewrote everything, it will merge this rewrite into the patch bottom, together with the patch itself. So, the merge time will depend on the biggest of the two changed trees, not on the least one.

A more reasonable algorithm would be along "read-tree HEAD"; merge "stg diff -r /" (i.e. the current patch) in it.

I don't know if there's any real difference between cg-Xmergefile, gitmergeonefile.py and git-merge-one-file-script, and if that would matter in this case.

* About --remove, it was called on files which were present in stage1, removed 
in stage2 (i.e. upstream) and unchanged in stage3 (i.e. patch).

In the git-read-tree manpage (which is probably outdated), this is documented as follows:

       o  stage 1 and stage 3 are the same and stage 2 is different: 
           take stage 2 (some work has been done on stage 2)

But it didn't happen, which is strange.

Additional note: in StGIT, git-read-tree is called with stage1 which is not the merge base between stage2 and stage3.

It is passed the patch bottom, the current HEAD and the patch top.

For the first patch, the patch bottom is the merge base, but not otherwise; so differences between either stage1 or stage3, and stage2, include files changed in previous patches.

So, would stgit delete a file created in patch #1 when merge-applying patch #2?