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

[Blaisorblade <blaisorblade@yahoo.it>]

(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?
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it