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

From: Shawn Pearce <spearce@spearce.org>
Date: Mar 10, 2006, 16:23 UTC
Message-ID: <20060310162322.GB7004@spearce.org>
In-Reply-To: <b0943d9e0603091400o2cd0291h@mail.gmail.com>

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

Show 15 quoted lines

> On 01/03/06, Shawn Pearce <spearce@spearce.org> wrote:
> > 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.
> 
> Trying to implement this, I've just noticed that git-read-tree has a
> --aggressive option which takes care of the file removals. Adding this
> option lowered the pushing time in StGIT from ~2 min to under 2
> seconds (merges between 2.6.14 and the latest kernel). There's
> probably no need to deal with file removals in pg--merge-all anymore.

Thanks for the heads up. I'll have to add that in. In case you didn't notice the list traffic I have added a --stage=all switch to git-checkout-index to grab into temporary files all unmerged stages.

I'm still working on integrating that into pg--merge-all but the idea is to save on the fork/exec of git-unpack-file when I get into the diff portion of the merge process. At least on Cygwin (a place where I'm really using pg) it will save time as the forks are so expensive there. Linux users may not see any improvement from it.

I also added --stdin to git-checkout-index but pg--merge-all is still using xargs. I just haven't had time to convert it over and push it up to my public repo. Hopefully I'll get both of those done this weekend.

I've started to get busy with an Eclipse plugin for GIT so my work with pg is likely going to slow down a little (besides its doing most of what I need at this point). But the next thing I was going to try to add to GIT to boost pg's performance was to integrate a diff library, so we aren't forking out a diff process for every file we need to extract a diff for.

-- 
Shawn.