Re: Rollback of git commands

On Wed, 28 Nov 2007, Steven Grimm wrote:

On Nov 28, 2007, at 1:47 PM, Daniel Barkalow wrote:

quoted

(That is, "git rebase -i" seems
to work fine for making changes to a single logical patch series, all of
whose patches are prepared locally and aren't independantly named in some
particular fashion; the things that aren't handled are "I need to replace
the pull of netdev.git with a new pull of netdev.git" or "I need to
replace '[PATCH] fix-the-frobnozzle-gadget' with
'[PATCH v2] fix-the-frobnozzle-gadget'.)

I use rebase -i for that last case and it works fine -- I mark the appropriate
commit as "edit" in the patch list and the rebase stops there, at which point
I can update the patch in any way I see fit: tweak it a bit, replace it with a
different change entirely, change the commit message, etc. What's missing from
rebase -i in that respect? I guess it's not as easy to script for automated
patch replacement.

Just that you have to find the patch yourself and replace it; if you're 
doing this a lot, you'll want to say "here's a new version of 
fix-the-frobnozzle-gadget, do the right thing". Also, for series items 
that are pulling some remote tree, you want it to remember the info, so 
you can just say "pull git-netdev" and have it fetch the latest from the 
appropriate remote and replace the merge commit with a new merge commit.

I think that people in this role using quilt do it by: "quilt pop -a; 
replace the patch file without looking at the series file; quilt push 
-a"; in the (hopefully) common case, you don't have to worry about any of 
the details, which is why the task remains tractable.

	-Daniel
*This .sig left intentionally blank*