Re: Some ideas for StGIT

From: Chris Shoemaker <c.shoemaker@cox.net>
Date: Aug 4, 2007, 14:14 UTC
Message-ID: <20070804141438.GA15821@pe.Belkin>
In-Reply-To: <1186206085.28481.33.camel@dv>

On Sat, Aug 04, 2007 at 01:41:25AM -0400, Pavel Roskin wrote:

Show 15 quoted lines

> Hello, Andy!
> 
> 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 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.

FWIW, I'm in the same camp. I'm a huge fan of quilt, and used it extensively and with large stacks. (Actually, I still use it whenever I don't want to bother with importing-to-git a large CVS or SVN project that I'm tracking.) When I started using git (and up until the first time I used git-rebase -i), I assumed I'd eventually have to use one of the quilt-like add-ons, but I wanted to hold off a little while until I was comfortable with core-git.

But, after using git-rebase -i, I can't see why I'd need any quilt-like add-on. Every time I use git-rebase -i, it's like I'm editing the patch stack.

Show 9 quoted lines

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

Well, there are many different ways one might want to modify the stack, but I find that most of them are quite easy with git-rebase -i. IMO, here are things that are easier with git-rebase -i than with an external patch stack:

   - editing the headers (git-rebase makes it easy to find/select the
       patch and even opens the editor for me)
   - reordering patches
   - combining patches (squashing)
   - moving one file's diff from one patch to another

IMO, here are some things that would probably be easier with an external patch stack:

   - directly editing the diff hunks
   - moving single diff hunks between patches

Maybe there are others, too, but these are things I just don't do nearly as frequently as the things that git-rebase -i is good at. (I use git-rebase -i *constantly*).

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

That sounds more like an argument from familiarity than anything else. Nobody (reasonable) directly hacks git's internal binary format. The "known format" I can hack with my editor is just the content itself. Honestly, when you have commit-handling that is as good as git's, there's really very little appeal left to editing the diffs directly.

-chris