[RFC] git-rebase-rewind, nested rebases, remembering stgit

[RFC] git-rebase-rewind, nested rebases, remembering stgit

[ydirson]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

Hello there,

I often find myself doing iterative refactorings, which can lead to
long branches, and while rebasing to edit HEAD~10 realize that I first
need to edit HEAD~20 or to add more commits below that stack.

If you've used stgit when it was a thing, you probably see how it
helped doing that.  While git-rebase has grown to do much more than
stgit in most areas, this is still one area where with a pain point
for me.

Here is a small git-rebase-rewind script I've been using for a few weeks,
starting with my most common use-case: automate worklow "edit git-rebase-todo
to prepend 'pick' commands for the N previous commits, then reset --hard HEAD~N".

As you will see from the new needs revealed by using this script (see in the
script header), I believe it would be valuable to integrate such a mechanism
directly into git-rebase.  Notably, "git rebase -i" itself can be seen as a
form of rewind, and this rewind feature would benefit from all the interactive
rebase work.

Does that sound like reasonable premises ?
-- 
Yann

[-- Attachment #2: git-rebase-rewind --]
[-- Type: application/x-shellscript, Size: 2465 bytes --]

Re: [RFC] git-rebase-rewind, nested rebases, remembering stgit

[Christian Couder]

Hi Yann,

Nice to hear from you on the list!

On Sat, Mar 13, 2021 at 5:45 PM <ydirson@free.fr> wrote:
>
> Hello there,
>
> I often find myself doing iterative refactorings, which can lead to
> long branches, and while rebasing to edit HEAD~10 realize that I first
> need to edit HEAD~20 or to add more commits below that stack.
>
> If you've used stgit when it was a thing, you probably see how it
> helped doing that.  While git-rebase has grown to do much more than
> stgit in most areas, this is still one area where with a pain point
> for me.
>
> Here is a small git-rebase-rewind script I've been using for a few weeks,
> starting with my most common use-case: automate worklow "edit git-rebase-todo
> to prepend 'pick' commands for the N previous commits, then reset --hard HEAD~N".
>
> As you will see from the new needs revealed by using this script (see in the
> script header), I believe it would be valuable to integrate such a mechanism
> directly into git-rebase.  Notably, "git rebase -i" itself can be seen as a
> form of rewind, and this rewind feature would benefit from all the interactive
> rebase work.
>
> Does that sound like reasonable premises ?

Sorry for the late answer. It sounds reasonable to me.

It looks to me like a way to restart the whole interactive rebase
process though, so I wonder if calling it "--restart" would be better
than "--rewind".

Re: [RFC] git-rebase-rewind, nested rebases, remembering stgit

[ydirson]

Hi Christian,

> De: "Christian Couder" <christian.couder@gmail.com>
> À: "Yann Dirson" <ydirson@free.fr>
> Cc: "git" <git@vger.kernel.org>
> Envoyé: Lundi 22 Mars 2021 09:49:23
> Objet: Re: [RFC] git-rebase-rewind, nested rebases, remembering stgit
> 
> Hi Yann,
> 
> Nice to hear from you on the list!
> 
> On Sat, Mar 13, 2021 at 5:45 PM <ydirson@free.fr> wrote:
> >
> > Hello there,
> >
> > I often find myself doing iterative refactorings, which can lead to
> > long branches, and while rebasing to edit HEAD~10 realize that I
> > first
> > need to edit HEAD~20 or to add more commits below that stack.
> >
> > If you've used stgit when it was a thing, you probably see how it
> > helped doing that.  While git-rebase has grown to do much more than
> > stgit in most areas, this is still one area where with a pain point
> > for me.
> >
> > Here is a small git-rebase-rewind script I've been using for a few
> > weeks,
> > starting with my most common use-case: automate worklow "edit
> > git-rebase-todo
> > to prepend 'pick' commands for the N previous commits, then reset
> > --hard HEAD~N".
> >
> > As you will see from the new needs revealed by using this script
> > (see in the
> > script header), I believe it would be valuable to integrate such a
> > mechanism
> > directly into git-rebase.  Notably, "git rebase -i" itself can be
> > seen as a
> > form of rewind, and this rewind feature would benefit from all the
> > interactive
> > rebase work.
> >
> > Does that sound like reasonable premises ?
> 
> Sorry for the late answer. It sounds reasonable to me.
> 
> It looks to me like a way to restart the whole interactive rebase
> process though, so I wonder if calling it "--restart" would be better
> than "--rewind".

Right, it is indeed like doing another interactive rebase while the
current one is not finished.  Maybe just running "rebase -i" without
more option could be sufficient ?  That could break the expectation
when someone relies on rebase refusing to proceed while already rebasing,
though it could be mitigated if a "rebase --abort" just aborts the
most recent rebase.

There are quite a few UI issues to be thought through around here :)