# [RFC] git-rebase-rewind, nested rebases, remembering stgit 3 messages from 2021-03-13 to 2021-03-22. Participants: ydirson@free.fr, Christian Couder. Thread: https://gitlist.dev/t/55309 ## ydirson@free.fr, 2021-03-13 16:37 Subject: [RFC] git-rebase-rewind, nested rebases, remembering stgit Message-ID: <139173043.431119331.1615653441685.JavaMail.root@zimbra39-e7> URL: https://gitlist.dev/e/139173043.431119331.1615653441685.JavaMail.root%40zimbra39-e7 In-Reply-To: <1641138664.431077840.1615652537045.JavaMail.root@zimbra39-e7> ``` 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 ``` ## Christian Couder, 2021-03-22 08:49 Subject: Re: [RFC] git-rebase-rewind, nested rebases, remembering stgit Message-ID: URL: https://gitlist.dev/e/CAP8UFD3r%2BkJTxYCvaToyQXO59PNJiZOfOFwUz7FzTfs%3DhMuHWQ%40mail.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 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". ``` ## ydirson@free.fr, 2021-03-22 09:33 Subject: Re: [RFC] git-rebase-rewind, nested rebases, remembering stgit Message-ID: <529810619.466659941.1616405628030.JavaMail.root@zimbra39-e7> URL: https://gitlist.dev/e/529810619.466659941.1616405628030.JavaMail.root%40zimbra39-e7 In-Reply-To: ``` Hi Christian, > De: "Christian Couder" > À: "Yann Dirson" > Cc: "git" > 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 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 :) ```