From: Shawn Pearce <spearce@spearce.org>
To: Catalin Marinas <catalin.marinas@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: bug?: stgit creates (unneccessary?) conflicts when pulling
Date: Fri, 10 Mar 2006 11:23:22 -0500 [thread overview]
Message-ID: <20060310162322.GB7004@spearce.org> (raw)
In-Reply-To: <b0943d9e0603091400o2cd0291h@mail.gmail.com>
Catalin Marinas <catalin.marinas@gmail.com> wrote:
> 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.
prev parent reply other threads:[~2006-03-10 16:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-27 20:42 bug?: stgit creates (unneccessary?) conflicts when pulling Karl Hasselström
2006-02-27 21:45 ` Sam Vilain
2006-02-27 22:17 ` Catalin Marinas
2006-02-28 15:00 ` Catalin Marinas
2006-02-28 18:53 ` Catalin Marinas
2006-02-28 22:45 ` Catalin Marinas
2006-03-01 17:39 ` Chuck Lever
2006-03-01 17:53 ` Catalin Marinas
2006-03-03 14:13 ` Karl Hasselström
2006-03-03 21:57 ` Catalin Marinas
2006-03-03 14:24 ` Karl Hasselström
2006-03-03 22:07 ` Catalin Marinas
2006-02-27 22:26 ` Shawn Pearce
2006-03-01 10:59 ` Catalin Marinas
2006-03-01 14:51 ` Shawn Pearce
2006-03-01 15:08 ` Catalin Marinas
2006-03-01 15:50 ` Shawn Pearce
2006-03-09 22:00 ` Catalin Marinas
2006-03-09 23:20 ` Junio C Hamano
2006-03-10 11:13 ` Catalin Marinas
2006-03-11 6:46 ` Junio C Hamano
2006-03-10 16:23 ` Shawn Pearce [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060310162322.GB7004@spearce.org \
--to=spearce@spearce.org \
--cc=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.