Re: Refactoring git-rebase.sh and git-rebase--interactive.sh

From: Yann Dirson <ydirson@free.fr>
Date: Nov 4, 2010, 21:15 UTC
Message-ID: <20101104211556.GB8911@home.lan>
In-Reply-To: <201011030424.33093.chriscool@tuxfamily.org>

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).

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 ?

-- 
Yann