On Sat, Aug 04, 2007 at 01:41:25AM -0400, Pavel Roskin wrote:
> 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.
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
