Catalin Marinas <catalin.marinas@gmail.com> wrote: > On 01/03/06, Shawn Pearce <spearce@spearce.org> wrote: > > True. The constant reapplication does really slow it down. So does > > grabbing the reverse patch and seeing if it applies backwards > > cleanly. Neither operation is fast, and neither is really going > > to be fast. > > I realised that, depending on the number of patches merged upstream, > using this option can make StGIT faster. That's because when pushing a > patch (without the --merged option), StGIT first tries a diff | apply > followed by a three-way merge (even slower) if the former method > fails. This means that for all the patches merged upstream, StGIT > tries both methods since diff | apply fails anyway. With the --merged > option, StGIT would only try the reverse-diff | apply and, if this > succeeds, it will skip the normal push methods. Speaking of making StGIT faster: earlier we were talking about how git-diff|git-apply is faster than a 3 way git-read-tree on large merges when there are many structural changes in the tree due to the smaller number of process spawns required. You might want to take a look at pg--merge-all: This is sort of based on git-merge-recursive, but I've gotten it down to just a handful of process spawns, aside from the stupidity of git-checkout-index. (My recent git-checkout-index patches are working to correct that.) -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Thu Mar 02 02:51:25 2006
This archive was generated by hypermail 2.1.8 : 2006-03-02 02:51:38 EST