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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Yann,

On Thu, Nov 4, 2010 at 10: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 :)

Yeah, but don't expect something soon because I am quite busy these days.

> 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 ?

If you want them, feel free to work on those options without waiting
for a sequencer.

Thanks,
Christian.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]