Re: bug?: stgit creates (unneccessary?) conflicts when pulling

From: Shawn Pearce <spearce@spearce.org>
Date: Mar 1, 2006, 15:50 UTC
Message-ID: <20060301155043.GA3706@spearce.org>
In-Reply-To: <b0943d9e0603010708l72cb14d1w@mail.gmail.com>

Catalin Marinas <catalin.marinas@gmail.com> wrote:

Show 14 quoted lines

> 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.