Re: Rollback of git commands

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Nov 28, 2007, 22:48 UTC
Message-ID: <Pine.LNX.4.64.0711281702140.5349@iabervon.org>
In-Reply-To: <795F24E6-9145-4007-95EB-DB63D9F6295A@midwinter.com>

On Wed, 28 Nov 2007, Steven Grimm wrote:

Show 15 quoted lines

> On Nov 28, 2007, at 1:47 PM, Daniel Barkalow wrote:
> >(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*