On Thu, Nov 4, 2010 at 3:15 PM, Yann Dirson <ydirson@xxxxxxx> wrote: > Hi Christian, > > On Wed, Nov 03, 2010 at 04:24:32AM +0100, Christian Couder wrote: >> Now that GTAC (http://www.gtac.biz) is over, I plan to work on options >> --continue, --abort and --skip for git cherry-pick/revert. After that I hope >> to be able to refactor the code so that in the end common code is used by >> cherry-pick/revert and rebase. > > Sounds like "sequencer is coming back", great news :) > > I don't know if you would like the idea enough, but something I often > think would be good to have (and which could be useful for cherry-pick > and other commands in need of a sequencer), would be more flexibility. > The thing I find myself lacking most often, is the possibility to > change my mind on an already-edited commit (ie, go back after > --continue), the alternatives I can see today being: > > - keeping a note on what to do on next pass (but may be more work in case > of conflicts with further commits) > - fast-forward --continue'ing to keep curent changes and add new ones in > next pass (same restriction) > - --abort'ing the rebase and starting it again, possibly fetching the > changes from previous run via HEAD's reflog (not very handy either) > - checkout back to where you want to re-amend and cherry-pick those you > already passed, essentially redoing an interactive rebase by hand > > If we could go back to previous commit, while keeping changes done to > the current one (say, --previous), or reverting to the original one > (say, --revert). In the same way, continuing until another > previously-unforeseen commit without the need to edit the todo file > would be nice to have (eg. --next). I've long wanted something like --next. That would save me a lot of multi-pass rebases. > While I'm at it, another somewhat loosely option I have thought of > would be to seed the todo file with "edit" commands instead of "pick", > to make it possible to validate a series of patches one by one before > sending. That could be generalized for running a test script > automatically, that is inserting "x whatever" between all pick's - and > my 1st idea would boil down to inserting arg-less "edit" or "x false" > instead. Maybe some --stepcmd=<command> flag ? Yes, --stepcmd would be *really* useful for testing a patch sequence or adding forgotten signed-off by's. > -- > Yann > -- > 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 > -- 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