Hi Elijah, hi Szeder, On Wed, Jan 08, 2020 at 02:06:22PM -0800, Elijah Newren wrote: > This looks like a known bug in rebase, in particular in the am-backend that > rebase uses by default. If I'm correct that it's just a context region > issue, then this is the same bug that was recently discussed at > https://lore.kernel.org/git/CAN_72e2h2avv-U9BVBYqXVKiC+5kHy-pjejyMSD3X22uRXE39g@xxxxxxxxxxxxxx/. > The current plan is to switch the default over to the merge backend (the > same machinery that cherry-pick uses), which doesn't suffer from the same > shortcomings (you can see the current work being done in this area at > https://lore.kernel.org/git/pull.679.v3.git.git.1577217299.gitgitgadget@xxxxxxxxx/ > ). Thank you for your feedback and references, here and in [*]. Once hit by this or similar issues, I think there is high chance for people to go through the same feelings as described by Pavel in [**]: --- That's so scary that I'm going to stop using "git rebase" for now. --- Some years ago I was hit by 'git merge' producing slightly different results compared to 'git rebase --onto' and 'git cherry-pick A..B' (maybe I can come up with a reproduction scenario for that too). Since then, I usually contrast the outcomes of merging, cherry-picking and rebasing, to make sure they match, but that's painful and time-consuming. > In the mean time, you can pass the -m flag to rebase to avoid these types > of problems. In fact, if you could retry with -m you may be able to > confirm whether it's the same issue. Indeed, neither `git rebase -m` nor `git rebase -i` exhibit the problem. [*] https://lore.kernel.org/git/CABPp-BHsy75UGm4wTOP2_AYik_dZi-_BxtAn-hyi-ZrNRRWGuw@xxxxxxxxxxxxxx/T/#m1cbf80ef56c260a626146d61291d7fbabd108f1b [**] https://lore.kernel.org/git/CAN_72e2h2avv-U9BVBYqXVKiC+5kHy-pjejyMSD3X22uRXE39g@xxxxxxxxxxxxxx/ Thanks again. -- Best Regards, Eugeniu
