Re: [RFC] git-rebase-rewind, nested rebases, remembering stgit
- From
Christian Couder <christian.couder@gmail.com>
- Date
- Mar 22, 2021, 08:49 UTC
- Message-ID
- <CAP8UFD3r+kJTxYCvaToyQXO59PNJiZOfOFwUz7FzTfs=hMuHWQ@mail.gmail.com>
- In-Reply-To
- <139173043.431119331.1615653441685.JavaMail.root@zimbra39-e7>
Hi Yann,
Nice to hear from you on the list!
On Sat, Mar 13, 2021 at 5:45 PM <ydirson@free.fr> wrote:
Show 23 quoted lines
> > 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".