On Thu, Jan 9, 2020 at 2:53 AM Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> wrote: > > 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. > --- Yep, I understand; that kind of feeling is why I wanted to jump in and try to help fix it. I want merge/rebase/cherry-pick to be reliable. > 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). If you can, I'd be interested to see it and take a look. I'd normally assume it was just some case where A..B included "evil" merge commits (merge commits that made additional changes not part of the actual merging) since rebasing or cherry-picking such a range would exclude the merge commits and thus drop those changes -- but you identified a real bug with the default rebase backend so I'm interested to see if you happen to have more bugs I should know about. > > 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. That's good news. Unfortunately, you should note that git-2.25 is going to have the same bug you reported; there are still some loose ends with my series to make -m the default, and the 2.25 release is expected within a few days, so my change of default won't happen until 2.26. (That series would have needed to be completed several weeks ago for it to go into 2.25).
