{"thread":{"id":"47828","subject":"git-rebase --undo-skip proposal","startedAt":"2018-02-13T20:23:05Z","lastAt":"2018-02-15T13:06:36Z","messageCount":10,"participants":["Psidium Guajava","Stefan Beller","Johannes Schindelin","Jacob Keller","Paul Tan"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"339231","messageId":"CAEWZXo7KiRWK7ddyZgQKs=F+sHY7TtFsXTMXyE-57=FRr6kf6w@mail.gmail.com","threadId":"47828","inReplyTo":null,"subject":"git-rebase --undo-skip proposal","fromName":"Psidium Guajava","fromEmail":"psiidium@gmail.com","sentAt":"2018-02-13T20:22:59Z","receivedAt":"2018-02-13T20:23:05Z","isPatch":false,"sender":{"key":"psiidium@gmail.com","avatar":"https://gravatar.com/avatar/f98e3013d65e7a932ef4ed824ba24bf54d43958181495897e36167a14ec21355?d=mp&s=160"},"body":"Hello git community,\n\nI'd like to add a new feature in git-rebase: --undo-skip.\nBut first, I'd like to consult with the experts if it would be\nbeneficial for the project and if my line of tought is correct.\n\nImagine that you are working on a feature for a long time, but there\nare multiple bug fixes happening at `master` branch at the same time.\nAfter lots of commits on both ends, you decide to rebase your changes\non top of the current `master` branch.\nAfter lots of conflict resolution steps, you mistakenly call\n`git-rebase --skip` instead of `git-rebase --continue`, thus losing a\ncommit of your work, and possibly inserting bugs in your project.\nThe only solution for this right now would be to abort the current\nrebase and start over.\n\nIt seems that a feature like this have been requested once on the mail list [1].\n\nI propose the existence of --undo-skip on git-rebase's `$action` domain.\n\nHow I fixed it when that happened with me was (just after running the\nwrong skip):\n\n1. I figured I was making a rebase that used `git-am` as a backend.\n2. In the rebase-apply directory I searched for the patch file with\nthe change I just skipped.\n3. Found the `rebase-apply/next` file.\n4. Wrote the number of the patch I skipped - 1 in rebase-apply/next.\n5. run `git rebase --skip` again on the repository.\n\nThis made the lost patch appear again and I could `--continue` it this time.\n\nI propose the addition of an action `--undo-skip`, that could be\ncalled only after a wrongfully called `--skip`.\n`git rebase --undo-skip`.\nI would implemented it to do programatically what I did by hand when\nthat happened with me.\n\nHere are my questions for you:\n1. Would this be beneficial for the users?\n2. For `rebase--am`, I would need to change `git-rebase--am.sh` file, correct?\n3. Can I assume `builtin/am.c` will always store its information on\n`$state_dir/next` and `$state_dir/$patchnumbers`?\n4. How hard would it be to add that logic for `rebase--interactive`\nand `rebase--merge` backends?\n\nAlso, a little unrelated with this issue:\n5. What happened to the rewrite of rebase in C [2]? I couldn't find\nany information after 2016.\n\n[1] https://public-inbox.org/git/201311011522.44631.thomas@koch.ro/\n[2] https://public-inbox.org/git/1457779597-6918-1-git-send-email-pyokagan@gmail.com/\n\n\nBest Regards,\nGabriel Borges\n"},{"id":"339233","messageId":"CAGZ79kZf1UKsBEJXuwAH+EWr+ZKj-FE8DuBvcM2nJeNhLEA4CQ@mail.gmail.com","threadId":"47828","inReplyTo":"CAEWZXo7KiRWK7ddyZgQKs=F+sHY7TtFsXTMXyE-57=FRr6kf6w@mail.gmail.com","subject":"Re: git-rebase --undo-skip proposal","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-02-13T20:42:45Z","receivedAt":"2018-02-13T20:42:52Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava wrote:\n> Hello git community,\n>\n> I'd like to add a new feature in git-rebase: --undo-skip.\n> But first, I'd like to consult with the experts if it would be\n> beneficial for the project and if my line of tought is correct.\n>\n> Imagine that you are working on a feature for a long time, but there\n> are multiple bug fixes happening at `master` branch at the same time.\n> After lots of commits on both ends, you decide to rebase your changes\n> on top of the current `master` branch.\n> After lots of conflict resolution steps, you mistakenly call\n> `git-rebase --skip` instead of `git-rebase --continue`, thus losing a\n> commit of your work, and possibly inserting bugs in your project.\n> The only solution for this right now would be to abort the current\n> rebase and start over.\n>\n> It seems that a feature like this have been requested once on the mail list [1].\n>\n> I propose the existence of --undo-skip on git-rebase's `$action` domain.\n>\n> How I fixed it when that happened with me was (just after running the\n> wrong skip):\n>\n> 1. I figured I was making a rebase that used `git-am` as a backend.\n> 2. In the rebase-apply directory I searched for the patch file with\n> the change I just skipped.\n> 3. Found the `rebase-apply/next` file.\n> 4. Wrote the number of the patch I skipped - 1 in rebase-apply/next.\n> 5. run `git rebase --skip` again on the repository.\n>\n> This made the lost patch appear again and I could `--continue` it this time.\n\nI think this could also be done with \"git rebase --edit-todo\", which brings\nup the right file in your editor.\n\n> I propose the addition of an action `--undo-skip`, that could be\n> called only after a wrongfully called `--skip`.\n> `git rebase --undo-skip`.\n> I would implemented it to do programatically what I did by hand when\n> that happened with me.\n>\n> Here are my questions for you:\n> 1. Would this be beneficial for the users?\n\nI guess it is.\n\n> 2. For `rebase--am`, I would need to change `git-rebase--am.sh` file, correct?\n> 3. Can I assume `builtin/am.c` will always store its information on\n> `$state_dir/next` and `$state_dir/$patchnumbers`?\n> 4. How hard would it be to add that logic for `rebase--interactive`\n> and `rebase--merge` backends?\n\ncc'd Johannes who is currently working on revamping rebase.\n\n>\n> Also, a little unrelated with this issue:\n> 5. What happened to the rewrite of rebase in C [2]? I couldn't find\n> any information after 2016.\n>\n> [1] https://public-inbox.org/git/201311011522.44631.thomas@koch.ro/\n> [2] https://public-inbox.org/git/1457779597-6918-1-git-send-email-pyokagan@gmail.com/\n\ncc'd Paul Tan, maybe he recalls the situation.\n"},{"id":"339422","messageId":"CAEWZXo6ws5q-73AP6+Ru39a+drO88fRO49_QGJbQXfOYRpqKwg@mail.gmail.com","threadId":"47828","inReplyTo":"CAGZ79kZf1UKsBEJXuwAH+EWr+ZKj-FE8DuBvcM2nJeNhLEA4CQ@mail.gmail.com","subject":"Re: git-rebase --undo-skip proposal","fromName":"Psidium Guajava","fromEmail":"psiidium@gmail.com","sentAt":"2018-02-15T00:36:44Z","receivedAt":"2018-02-15T00:37:03Z","isPatch":false,"sender":{"key":"psiidium@gmail.com","avatar":"https://gravatar.com/avatar/f98e3013d65e7a932ef4ed824ba24bf54d43958181495897e36167a14ec21355?d=mp&s=160"},"body":"On 2018-02-13 18:42 GMT-02:00 Stefan Beller wrote:\n> On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava wrote:\n> I think this could also be done with \"git rebase --edit-todo\", which brings\n> up the right file in your editor.\n\nYeah that'd would only work if one started a rebase as a interactive\none, not am or merge.\n\n> cc'd Paul Tan, maybe he recalls the situation.\n\nFrom what I've found on the archive, he didn't recently answer mails\nthat come from the mail list, I could be wrong tho.\n"},{"id":"339423","messageId":"nycvar.QRO.7.76.6.1802150148040.35@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"47828","inReplyTo":"CAEWZXo6ws5q-73AP6+Ru39a+drO88fRO49_QGJbQXfOYRpqKwg@mail.gmail.com","subject":"Re: git-rebase --undo-skip proposal","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-02-15T00:53:14Z","receivedAt":"2018-02-15T00:53:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 14 Feb 2018, Psidium Guajava wrote:\n\n> On 2018-02-13 18:42 GMT-02:00 Stefan Beller wrote:\n> > On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava wrote:\n> > I think this could also be done with \"git rebase --edit-todo\", which brings\n> > up the right file in your editor.\n> \n> Yeah that'd would only work if one started a rebase as a interactive\n> one, not am or merge.\n\nI agree that the original proposal was clearly for the non-interactive\nrebase (it talked about .git/rebase-apply/).\n\nThe biggest problem with the feature request is not how useful it would\nbe: I agree it would be useful. The biggest problem is that it is a little\nbit of an ill-defined problem.\n\nImagine that you are rebasing 30 patches. Now, let's assume that patch #7\ncauses a merge conflict, and you mistakenly call `git rebase --skip`.\n\nNow, when is the next possible time you can call `git rebase --undo-skip`?\nIt could be after a merge conflict in #8. Or in interactive rebase, after\na `pick` that was turned into an `edit`. Or, and this is also entirely\npossible, after the rebase finished with #30 without problems and the\nrebase is actually no longer in progress.\n\nSo I do not think that there is a way, in general, to implement this\nfeature. Even if you try to remember the state where a `--skip` was\ncalled, you would remember it in the .git/rebase-apply/ (or\n.git/rebase-merge/) directory, which is cleaned up after the rebase\nconcluded successfully. So even then the information required to implement\nthe feature would not necessarily be there, still, when it would be needed.\n\nCiao,\nJohannes\n"},{"id":"339426","messageId":"CA+P7+xrNPe5106qSjs1BiGJ5RbVxmR=MiGNVeCAUbT3gR0cdLw@mail.gmail.com","threadId":"47828","inReplyTo":"nycvar.QRO.7.76.6.1802150148040.35@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","subject":"Re: git-rebase --undo-skip proposal","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2018-02-15T01:23:33Z","receivedAt":"2018-02-15T01:24:01Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Feb 14, 2018 at 4:53 PM, Johannes Schindelin\n wrote:\n> Hi,\n>\n> On Wed, 14 Feb 2018, Psidium Guajava wrote:\n>\n>> On 2018-02-13 18:42 GMT-02:00 Stefan Beller wrote:\n>> > On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava wrote:\n>> > I think this could also be done with \"git rebase --edit-todo\", which brings\n>> > up the right file in your editor.\n>>\n>> Yeah that'd would only work if one started a rebase as a interactive\n>> one, not am or merge.\n>\n> I agree that the original proposal was clearly for the non-interactive\n> rebase (it talked about .git/rebase-apply/).\n>\n> The biggest problem with the feature request is not how useful it would\n> be: I agree it would be useful. The biggest problem is that it is a little\n> bit of an ill-defined problem.\n>\n> Imagine that you are rebasing 30 patches. Now, let's assume that patch #7\n> causes a merge conflict, and you mistakenly call `git rebase --skip`.\n>\n> Now, when is the next possible time you can call `git rebase --undo-skip`?\n> It could be after a merge conflict in #8. Or in interactive rebase, after\n> a `pick` that was turned into an `edit`. Or, and this is also entirely\n> possible, after the rebase finished with #30 without problems and the\n> rebase is actually no longer in progress.\n>\n> So I do not think that there is a way, in general, to implement this\n> feature. Even if you try to remember the state where a `--skip` was\n> called, you would remember it in the .git/rebase-apply/ (or\n> .git/rebase-merge/) directory, which is cleaned up after the rebase\n> concluded successfully. So even then the information required to implement\n> the feature would not necessarily be there, still, when it would be needed.\n>\n> Ciao,\n> Johannes\n\nInstead of an \"--undo-skip\", what if we ask the question of what the\nuser actually wants?\n\nGenerally I'd assume that the user wishes to go back to the rebase and\n\"pick\" the commit back in.\n\nSo what if we just make \"git rebase --skip\" more verbose so that it\nmore clearly spells out which commit is being skipped? Possibly even\nas extra lines of \"the following patches were skipped during the\nrebase\" after it completes?\n\nThen it's up to the user to determine what to do with those commits,\nand there are many tools they could use to solve it, \"git rebase -i,\ngit cherry-pick, git reflog to restore to a previous and re-run the\nrebase, etc\".\n\nThanks,\nJake\n"},{"id":"339428","messageId":"CAEWZXo74Z0PRkVPzkrMDdKNhLzyKL03vUYiN=SEnt5MBdXT81A@mail.gmail.com","threadId":"47828","inReplyTo":"nycvar.QRO.7.76.6.1802150148040.35@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","subject":"Re: git-rebase --undo-skip proposal","fromName":"Psidium Guajava","fromEmail":"psiidium@gmail.com","sentAt":"2018-02-15T01:50:07Z","receivedAt":"2018-02-15T01:50:13Z","isPatch":false,"sender":{"key":"psiidium@gmail.com","avatar":"https://gravatar.com/avatar/f98e3013d65e7a932ef4ed824ba24bf54d43958181495897e36167a14ec21355?d=mp&s=160"},"body":"2018-02-14 22:53 GMT-02:00 Johannes Schindelin :\n> Now, when is the next possible time you can call `git rebase --undo-skip`?\n\nWhat if the scope were reduced from `--undo-skip` to `--undo-last-skip`?\nAlso, further reduce the scope to only allow `--undo-last-skip` during\na ongoing rebase, not caring about a finished one?\n\nBut, this could be so niche that I have doubts if this would ever be used;\n"},{"id":"339432","messageId":"CA+P7+xpBW7Sq89f5RK6cCcLYGR0Rh0aWdWrhqjerKUi5xUUKtQ@mail.gmail.com","threadId":"47828","inReplyTo":"CAEWZXo74Z0PRkVPzkrMDdKNhLzyKL03vUYiN=SEnt5MBdXT81A@mail.gmail.com","subject":"Re: git-rebase --undo-skip proposal","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2018-02-15T04:50:27Z","receivedAt":"2018-02-15T04:50:55Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Feb 14, 2018 at 5:50 PM, Psidium Guajava wrote:\n> 2018-02-14 22:53 GMT-02:00 Johannes Schindelin :\n>> Now, when is the next possible time you can call `git rebase --undo-skip`?\n>\n> What if the scope were reduced from `--undo-skip` to `--undo-last-skip`?\n> Also, further reduce the scope to only allow `--undo-last-skip` during\n> a ongoing rebase, not caring about a finished one?\n>\n> But, this could be so niche that I have doubts if this would ever be used;\n\nI think this is too niche to actually be useful in practice,\nespecially since figuring out exactly what to replay might be tricky..\nI suppose it could keep track of where in the rebase the last skip was\nused, and then just go back to rebase and stop there again? That\nsounds like just redoing the rebase is easier.. (ie: use the reflog to\ngo back to before the rebase started, and then re-run it again and\ndon't skip this time).\n"},{"id":"339458","messageId":"CACRoPnROrHbdOf_dCbYhGXSnqM4gowj_s50RcH+8vWgU+deCdw@mail.gmail.com","threadId":"47828","inReplyTo":"CAGZ79kZf1UKsBEJXuwAH+EWr+ZKj-FE8DuBvcM2nJeNhLEA4CQ@mail.gmail.com","subject":"Re: git-rebase --undo-skip proposal","fromName":"Paul Tan","fromEmail":"pyokagan@gmail.com","sentAt":"2018-02-15T10:11:41Z","receivedAt":"2018-02-15T10:11:47Z","isPatch":false,"sender":{"key":"pyokagan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/109479?v=4"},"body":"Hi Gabriel,\n\nOn Wed, Feb 14, 2018 at 4:42 AM, Stefan Beller wrote:\n> On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava wrote:\n>>\n>> Also, a little unrelated with this issue:\n>> 5. What happened to the rewrite of rebase in C [2]? I couldn't find\n>> any information after 2016.\n>>\n>> [1] https://public-inbox.org/git/201311011522.44631.thomas@koch.ro/\n>> [2] https://public-inbox.org/git/1457779597-6918-1-git-send-email-pyokagan@gmail.com/\n>\n> cc'd Paul Tan, maybe he recalls the situation.\n\nIt was discarded in favor of Johannes' rebase-helper approach, and I\nthink parts of it are already in master. There's probably room for\nhelp there.\n\nI haven't had time to keep track of Git development, hence my\ninactivity. Sorry about that.\n\nRegards,\nPaul\n"},{"id":"339468","messageId":"nycvar.QRO.7.76.6.1802151308501.35@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"47828","inReplyTo":"CA+P7+xrNPe5106qSjs1BiGJ5RbVxmR=MiGNVeCAUbT3gR0cdLw@mail.gmail.com","subject":"Re: git-rebase --undo-skip proposal","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-02-15T13:02:48Z","receivedAt":"2018-02-15T13:02:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Jake,\n\nOn Wed, 14 Feb 2018, Jacob Keller wrote:\n\n> On Wed, Feb 14, 2018 at 4:53 PM, Johannes Schindelin\n> wrote:\n> >\n> > On Wed, 14 Feb 2018, Psidium Guajava wrote:\n> >\n> >> On 2018-02-13 18:42 GMT-02:00 Stefan Beller wrote:\n> >> > On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava\n> >> > wrote: I think this could also be done with\n> >> > \"git rebase --edit-todo\", which brings up the right file in your\n> >> > editor.\n> >>\n> >> Yeah that'd would only work if one started a rebase as a interactive\n> >> one, not am or merge.\n> >\n> > I agree that the original proposal was clearly for the non-interactive\n> > rebase (it talked about .git/rebase-apply/).\n> >\n> > The biggest problem with the feature request is not how useful it\n> > would be: I agree it would be useful. The biggest problem is that it\n> > is a little bit of an ill-defined problem.\n> >\n> > Imagine that you are rebasing 30 patches. Now, let's assume that patch\n> > #7 causes a merge conflict, and you mistakenly call `git rebase\n> > --skip`.\n> >\n> > Now, when is the next possible time you can call `git rebase\n> > --undo-skip`? It could be after a merge conflict in #8. Or in\n> > interactive rebase, after a `pick` that was turned into an `edit`. Or,\n> > and this is also entirely possible, after the rebase finished with #30\n> > without problems and the rebase is actually no longer in progress.\n> >\n> > So I do not think that there is a way, in general, to implement this\n> > feature. Even if you try to remember the state where a `--skip` was\n> > called, you would remember it in the .git/rebase-apply/ (or\n> > .git/rebase-merge/) directory, which is cleaned up after the rebase\n> > concluded successfully. So even then the information required to\n> > implement the feature would not necessarily be there, still, when it\n> > would be needed.\n> \n> Instead of an \"--undo-skip\", what if we ask the question of what the\n> user actually wants?\n\nHeh, I thought in this instance, --undo-skip was what the user wanted ;-)\n\n> Generally I'd assume that the user wishes to go back to the rebase and\n> \"pick\" the commit back in.\n\nRight, and then replay whatever series of commits was picked since the one\nthat was skipped.\n\nWhat *could* be done is to save a copy of the current todo list (with the\nskipped commit put back in, before the current first line) and save that\ntogether with `git rev-parse HEAD`.\n\nThis should make it possible to implement `--undo-skip` for as long as\nthe rebase did not finish.\n\nTheoretically, you could even save the commit name of the skipped commit\nsomewhere else than $GIT_DIR/rebase-apply/ (or $GIT_DIR/rebase-merge/),\nsay, as worktree-local `refs/rebase/skipped`, and then a `git rebase\n--undo-skip` could detect the absence of $GIT_DIR/rebase-*/ and fall back\nto `git cherry-pick refs/rebase/skipped`.\n\nYou'd have to take pains to handle that ref in gc, and to record when the\nuser edited the todo list via `git rebase --edit-todo` after skipping that\ncommit (and warn loudly upon/prevent --undo-skip) because those todo list\nchanges would then be lost.\n\nThat's just one way how this feature could be implemented.\n\nIt does strike me as awfully specific, though. And it would still only\nextend to the latest `git rebase --skip`.\n\nSo I am not sure whether we really would want to go this direction, or\nwhether we can maybe come up with something (probably based on your\nsuggestion to give the user enough information) that would allow many more\nscenarios than just --undo-skip.\n\n> So what if we just make \"git rebase --skip\" more verbose so that it\n> more clearly spells out which commit is being skipped? Possibly even\n> as extra lines of \"the following patches were skipped during the\n> rebase\" after it completes?\n> \n> Then it's up to the user to determine what to do with those commits,\n> and there are many tools they could use to solve it, \"git rebase -i,\n> git cherry-pick, git reflog to restore to a previous and re-run the\n> rebase, etc\".\n\nI think this is a saner direction, as it will probably allow more\nscenarios to be addressed than just undoing the latest `git rebase\n--skip`.\n\nCiao,\nDscho\n"},{"id":"339469","messageId":"nycvar.QRO.7.76.6.1802151403360.35@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"47828","inReplyTo":"CA+P7+xpBW7Sq89f5RK6cCcLYGR0Rh0aWdWrhqjerKUi5xUUKtQ@mail.gmail.com","subject":"Re: git-rebase --undo-skip proposal","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-02-15T13:06:27Z","receivedAt":"2018-02-15T13:06:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Jake,\n\nOn Wed, 14 Feb 2018, Jacob Keller wrote:\n\n> On Wed, Feb 14, 2018 at 5:50 PM, Psidium Guajava wrote:\n> > 2018-02-14 22:53 GMT-02:00 Johannes Schindelin :\n> >> Now, when is the next possible time you can call `git rebase --undo-skip`?\n> >\n> > What if the scope were reduced from `--undo-skip` to `--undo-last-skip`?\n> > Also, further reduce the scope to only allow `--undo-last-skip` during\n> > a ongoing rebase, not caring about a finished one?\n> >\n> > But, this could be so niche that I have doubts if this would ever be used;\n> \n> I think this is too niche to actually be useful in practice,\n> especially since figuring out exactly what to replay might be tricky..\n> I suppose it could keep track of where in the rebase the last skip was\n> used, and then just go back to rebase and stop there again? That\n> sounds like just redoing the rebase is easier.. (ie: use the reflog to\n> go back to before the rebase started, and then re-run it again and\n> don't skip this time).\n\nYes, and having a record of what commits were skipped would probably be\nvery helpful not only in this instance.\n\nMaybe also a record of what commits caused merge conflicts, which a\nmapping between original and new commit (which does get a bit tricky with\nfixup!/squash! commits, though).\n\nCiao,\nDscho\n"}]}