On Fri, May 10, 2019 at 3:54 AM Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > Hi Junio & Duy, > > On Thu, 9 May 2019, Junio C Hamano wrote: > > > * nd/merge-quit (2019-05-07) 2 commits > > - merge: add --quit > > - merge: remove drop_save() in favor of remove_merge_branch_state() > > > > "git merge" learned "--quit" option that cleans up the in-progress > > merge while leaving the working tree and the index still in a mess. > > > > Hmph, why is this a good idea? > > It also seems to work *only* on Linux. At least the tests break on macOS > and on Windows: > > https://dev.azure.com/gitgitgadget/git/_build/results?buildId=8313&view=ms.vss-test-web.build-test-results-tab Sorry I have no idea what the problem is. That's basically the same as the 'merge detects mod-256 conflicts (recursive)' test earlier but with rerere enabled. It does not even look like some leftover rerere records accidentally fix the conflict. I tried with a case-insensitive filesytem (on linux) and with --valgrind, no problem found. Travis on pu seemed ok with t7600 on mac. One difference I notice is the the failed test looks like it found the wrong merge base found 1 common ancestor: c4c4222 commit 1 while my tests have "commit 0" as the base. "git log --graph --oneline" indicates "commit 1" is the wrong base. Something is wrong with the merge code (this has not even reached the new --quit code). I could change the setup steps to be more stable, using a simpler commit history, but this looks like something we should find and fix. > Sadly, I ran out of time do look into this (I am pretty busy preparing Git > for Windows for v2.22.0-rc0). > > Ciao, > Dscho -- Duy
