Hi Eugeniu, On Thu, Jan 9, 2020 at 4:06 PM Eugeniu Rosca <roscaeugeniu@xxxxxxxxx> wrote: > > 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? Ooh, interesting case; thanks for sending it along. I think this is the same as https://lore.kernel.org/git/20190816184051.GB13894@xxxxxxxxxxxxxxxxxxxxx/ , which struck git itself not that long back. It didn't do any actual harm, though, it was just surprising. I'm not familiar with the xdiff part of the codebase, so I don't know if this is a heuristic thing, or something more along the lines of the diff3 issues mentioned at https://www.cis.upenn.edu/~bcpierce/papers/diff3-short.pdf. I read up on this area a little bit a few months ago and I'd like to dig more at the diff3 stuff in general, but it may be a little while. If you see more issues like this, though, I'm definitely interested in saving and cataloging them for when I get back to this. Elijah
