On Wed, 28 Nov 2007, Steven Grimm wrote: > 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* - 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
