git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Pavel Roskin <proski@gnu.org>
Cc: Andy Parkins <andyparkins@gmail.com>,
	git@vger.kernel.org, Catalin Marinas <catalin.marinas@gmail.com>
Subject: Re: Some ideas for StGIT
Date: Sat, 4 Aug 2007 01:51:11 -0400	[thread overview]
Message-ID: <20070804055110.GP20052@spearce.org> (raw)
In-Reply-To: <1186206085.28481.33.camel@dv>

Pavel Roskin <proski@gnu.org> wrote:
> 
> On Fri, 2007-08-03 at 19:14 +0100, Andy Parkins wrote:
> > On Friday 2007, August 03, Pavel Roskin wrote:
> > 
> > > I don't suggest that StGIT gives up on the git-based storage, but this
> > > mode of operation could be implemented in two ways.
> > 
> > git's shiny new git rebase -i has removed, for me, those times when I needed 
> > stgit.  Perhaps those who've move from git to quilt would try again when 
> > 1.5.3 is out with the magic that is "rebase -i".

I agree with Andy.  Aside from the performance issues that I
am currently having with a 55 patch series, "rebase -i" (and its
predecessor script from Dscho) have been a major part of my toolkit,
to the point that I really don't need something like StGIT on
my system.

(Regarding the performance, cherry-picking 55 patches is
slow, especially when many of them would apply trivially with
git-diff|git-apply --index.  Be nice to improve that in 1.5.4.)
 
> I don't understand how one option can replace StGIT.  I assume you were
> trying to avoid StGIT already, and "git-rebase -i" was just the last
> missing piece.

Oh, I'm sure there's features in StGIT that are useful that aren't
available via "rebase -i".  But to be honest, "rebase -i" is good
enough.  It just ain't fast enough.  Editing a patch that is 50
back in the series *sucks*.
 
> It would be great if you could tell me how your approach would deal with
> the issue of editable patches I mentioned already.  In case I was
> unclear, here's the quote from one of the developers:
> 
> [quote]
> Sometimes, I just make patches in quilt, then I do "quilt 
> refresh", "quilt pop -a", "cd patches" and modify the patches 
> and series file manually, e.g. by moving one patch from one file 
> into the other. The "cd ..", "quilt push -a" and off I am. That 
> the "database" of quilt is in a known format and I can hack on 
> it with an editor is a plus for me :-)
> [end of quote]

Uh, the "database" of "rebase -i" is just a chain of commits in a
git repository.  These are a well known format and can be easily
edited with "rebase -i".  This is a real plus for me as the series
can be edited directly in my favorite vi clone, then applied to my
working directory.  ;-)

-- 
Shawn.

  reply	other threads:[~2007-08-04  5:51 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-03 17:50 Some ideas for StGIT Pavel Roskin
2007-08-03 18:14 ` Andy Parkins
2007-08-04  5:41   ` Pavel Roskin
2007-08-04  5:51     ` Shawn O. Pearce [this message]
2007-08-05  0:08       ` Pavel Roskin
2007-08-05  0:17       ` Jakub Narebski
2007-08-05  2:31         ` Shawn O. Pearce
2007-08-05  3:32           ` Junio C Hamano
2007-08-05 13:39           ` Josef Sipek
2007-08-05 13:56             ` Johannes Schindelin
2007-08-05 14:06               ` Josef Sipek
2007-08-05 14:15                 ` Johannes Schindelin
2007-08-05 14:57                   ` Josef Sipek
2007-08-04  8:08     ` Yann Dirson
2007-08-06 10:01       ` Catalin Marinas
2007-08-04 14:14     ` Chris Shoemaker
2007-08-04 15:22       ` Johannes Schindelin
2007-08-03 23:23 ` Yann Dirson
2007-08-06  9:49   ` Catalin Marinas
2007-08-06 13:26     ` Pavel Roskin
2007-08-06 15:19       ` Josef Sipek
2007-08-04  6:38 ` Theodore Tso
2007-08-04  8:16   ` Yann Dirson
2007-08-04 21:35   ` Josef Sipek
2007-08-05  0:12     ` Pavel Roskin
2007-08-06  9:36 ` Catalin Marinas
2007-08-06  9:56   ` Karl Hasselström
2007-08-06 12:42     ` Pavel Roskin
2007-08-06 13:52       ` Karl Hasselström
2007-08-23 14:09         ` Catalin Marinas
2007-08-23 14:34           ` Karl Hasselström
2007-08-06 17:17   ` Pavel Roskin

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=20070804055110.GP20052@spearce.org \
    --to=spearce@spearce.org \
    --cc=andyparkins@gmail.com \
    --cc=catalin.marinas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=proski@gnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).