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
Hi Yann,
Nice to hear from you on the list!
On Sat, Mar 13, 2021 at 5:45 PM [off-list ref] 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".
Hi Christian,
De: "Christian Couder" [off-list ref]
À: "Yann Dirson" [off-list ref]
Cc: "git" <redacted>
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 [off-list ref] wrote:
quoted
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 :)