{"thread":{"id":"55309","subject":"[RFC] git-rebase-rewind, nested rebases, remembering stgit","startedAt":"2021-03-13T16:38:55Z","lastAt":"2021-03-22T09:35:16Z","messageCount":3,"participants":["ydirson@free.fr","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"419046","messageId":"139173043.431119331.1615653441685.JavaMail.root@zimbra39-e7","threadId":"55309","inReplyTo":"1641138664.431077840.1615652537045.JavaMail.root@zimbra39-e7","subject":"[RFC] git-rebase-rewind, nested rebases, remembering stgit","fromName":"","fromEmail":"ydirson@free.fr","sentAt":"2021-03-13T16:37:21Z","receivedAt":"2021-03-13T16:38:55Z","isPatch":false,"sender":{"key":"ydirson@free.fr","avatar":null},"body":"Hello there,\n\nI often find myself doing iterative refactorings, which can lead to\nlong branches, and while rebasing to edit HEAD~10 realize that I first\nneed to edit HEAD~20 or to add more commits below that stack.\n\nIf you've used stgit when it was a thing, you probably see how it\nhelped doing that. While git-rebase has grown to do much more than\nstgit in most areas, this is still one area where with a pain point\nfor me.\n\nHere is a small git-rebase-rewind script I've been using for a few weeks,\nstarting with my most common use-case: automate worklow \"edit git-rebase-todo\nto prepend 'pick' commands for the N previous commits, then reset --hard HEAD~N\".\n\nAs you will see from the new needs revealed by using this script (see in the\nscript header), I believe it would be valuable to integrate such a mechanism\ndirectly into git-rebase. Notably, \"git rebase -i\" itself can be seen as a\nform of rewind, and this rewind feature would benefit from all the interactive\nrebase work.\n\nDoes that sound like reasonable premises ?\n-- \nYann\n"},{"id":"419914","messageId":"CAP8UFD3r+kJTxYCvaToyQXO59PNJiZOfOFwUz7FzTfs=hMuHWQ@mail.gmail.com","threadId":"55309","inReplyTo":"139173043.431119331.1615653441685.JavaMail.root@zimbra39-e7","subject":"Re: [RFC] git-rebase-rewind, nested rebases, remembering stgit","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2021-03-22T08:49:23Z","receivedAt":"2021-03-22T08:50:43Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Yann,\n\nNice to hear from you on the list!\n\nOn Sat, Mar 13, 2021 at 5:45 PM wrote:\n>\n> Hello there,\n>\n> I often find myself doing iterative refactorings, which can lead to\n> long branches, and while rebasing to edit HEAD~10 realize that I first\n> need to edit HEAD~20 or to add more commits below that stack.\n>\n> If you've used stgit when it was a thing, you probably see how it\n> helped doing that. While git-rebase has grown to do much more than\n> stgit in most areas, this is still one area where with a pain point\n> for me.\n>\n> Here is a small git-rebase-rewind script I've been using for a few weeks,\n> starting with my most common use-case: automate worklow \"edit git-rebase-todo\n> to prepend 'pick' commands for the N previous commits, then reset --hard HEAD~N\".\n>\n> As you will see from the new needs revealed by using this script (see in the\n> script header), I believe it would be valuable to integrate such a mechanism\n> directly into git-rebase. Notably, \"git rebase -i\" itself can be seen as a\n> form of rewind, and this rewind feature would benefit from all the interactive\n> rebase work.\n>\n> Does that sound like reasonable premises ?\n\nSorry for the late answer. It sounds reasonable to me.\n\nIt looks to me like a way to restart the whole interactive rebase\nprocess though, so I wonder if calling it \"--restart\" would be better\nthan \"--rewind\".\n"},{"id":"419916","messageId":"529810619.466659941.1616405628030.JavaMail.root@zimbra39-e7","threadId":"55309","inReplyTo":"CAP8UFD3r+kJTxYCvaToyQXO59PNJiZOfOFwUz7FzTfs=hMuHWQ@mail.gmail.com","subject":"Re: [RFC] git-rebase-rewind, nested rebases, remembering stgit","fromName":"","fromEmail":"ydirson@free.fr","sentAt":"2021-03-22T09:33:48Z","receivedAt":"2021-03-22T09:35:16Z","isPatch":false,"sender":{"key":"ydirson@free.fr","avatar":null},"body":"Hi Christian,\n\n> De: \"Christian Couder\" \n> À: \"Yann Dirson\" \n> Cc: \"git\" \n> Envoyé: Lundi 22 Mars 2021 09:49:23\n> Objet: Re: [RFC] git-rebase-rewind, nested rebases, remembering stgit\n> \n> Hi Yann,\n> \n> Nice to hear from you on the list!\n> \n> On Sat, Mar 13, 2021 at 5:45 PM wrote:\n> >\n> > Hello there,\n> >\n> > I often find myself doing iterative refactorings, which can lead to\n> > long branches, and while rebasing to edit HEAD~10 realize that I\n> > first\n> > need to edit HEAD~20 or to add more commits below that stack.\n> >\n> > If you've used stgit when it was a thing, you probably see how it\n> > helped doing that. While git-rebase has grown to do much more than\n> > stgit in most areas, this is still one area where with a pain point\n> > for me.\n> >\n> > Here is a small git-rebase-rewind script I've been using for a few\n> > weeks,\n> > starting with my most common use-case: automate worklow \"edit\n> > git-rebase-todo\n> > to prepend 'pick' commands for the N previous commits, then reset\n> > --hard HEAD~N\".\n> >\n> > As you will see from the new needs revealed by using this script\n> > (see in the\n> > script header), I believe it would be valuable to integrate such a\n> > mechanism\n> > directly into git-rebase. Notably, \"git rebase -i\" itself can be\n> > seen as a\n> > form of rewind, and this rewind feature would benefit from all the\n> > interactive\n> > rebase work.\n> >\n> > Does that sound like reasonable premises ?\n> \n> Sorry for the late answer. It sounds reasonable to me.\n> \n> It looks to me like a way to restart the whole interactive rebase\n> process though, so I wonder if calling it \"--restart\" would be better\n> than \"--rewind\".\n\nRight, it is indeed like doing another interactive rebase while the\ncurrent one is not finished. Maybe just running \"rebase -i\" without\nmore option could be sufficient ? That could break the expectation\nwhen someone relies on rebase refusing to proceed while already rebasing,\nthough it could be mitigated if a \"rebase --abort\" just aborts the\nmost recent rebase.\n\nThere are quite a few UI issues to be thought through around here :)\n\n\n"}]}