Hi Elijah, On Thu, Jan 09, 2020 at 10:05:52AM -0800, Elijah Newren wrote: > On Thu, Jan 9, 2020 at 2:53 AM Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> wrote: > > 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. Here is a _simplified_ scenario to get a totally unexpected result from 'git merge' (initially reproduced years ago, but still happening on 2.25.0.rc2): ## Preparation 0. git --version git version 2.25.0.rc2 1. git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2. git remote add linux-stable https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 3. git fetch linux-stable # Reproduction 4. git checkout f7a8e38f07a1 5. git merge --no-edit e18da11fc0f959 ## Merge v4.4.3 commit https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e18da11fc0f959 which is a linux-stable backport of vanilla v4.5-rc1 commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7a8e38f07a1 the latter being checked out at step 4. 6. git show HEAD ## Inspect the _automatic_ conflict resolution performed by git in drivers/mtd/nand/nand_base.c. Git decided to integrate e18da11fc0f959 alongside f7a8e38f07a1, while essentially they are the same commit. We end up with two times commit f7a8e38f07a1. What do you think about that? > 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). Thanks for this piece of information and for the time/effort spent! -- Best Regards, Eugeniu
