Hi,

On Sat, 4 Aug 2007, Chris Shoemaker wrote:

quoted text
> 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*).

Good to hear!  (I almost missed this mail, since I usually skip the StGit 
mails.)

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

Of course, you _could_ just export the patches as one mbox, edit them, and 
reapply them:

	git format-patch --stdout HEAD~4 > mbox.txt
	$EDITOR mbox.txt # even moving hunks
	git reset --hard HEAD~4
	git am mbox.txt

If the need is great enough, it should be easy to hack something like this 
into git rebase -i.

Ciao,
Dscho

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html