On Tue, Mar 31, 2020 at 11:35 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > On Tue, Mar 31, 2020 at 4:25 PM Bryan Turner <bturner@xxxxxxxxxxxxx> wrote: > > > > Using our merge test repository[1], one such test performs the following steps: > > * Unzip bare repository > > * `git clone --shared -b branch_that_differ_by_empty_commit_trgt > > <unzipped> rebase-test` > > * `git rebase -q --no-verify 7549846524f8aed2bd1c0249993ae1bf9d3c9998 > > 298924b8c403240eaf89dcda0cce7271620ab2f6` > > > > 298924b8c40 is an empty commit (i.e. `git commit --allow-empty`), and > > is the only commit not already reachable from 7549846524f. > > > > On Linux, when this test completes, "HEAD" in "rebase-test" is > > 7549846524f because the empty commit was discarded. This is the > > expected behavior. On Windows, "HEAD" is a new empty commit, which > > causes our test to fail. > > I don't have a Windows box to test, but it's good that you are seeing > the correct behavior there. I do have a Linux box, and cannot > duplicate the behavior you state, even downloading the zip you > mentioned and following your steps to reproduce. Actually, I did > reproduce that behavior the first time because I was accidentally > using git-2.25.0. But with git-2.26.0 on Linux, I see a new empty > commit after rebasing, as expected. > > Is there any chance you accidentally ran with an older git version > when on Linux? If you really were using git 2.26.0 on Linux...then > I'm totally confused at how you got that behavior. I went back through our build logs and confirmed that we _are_ running Git 2.26 (phew). I then set up a local Git 2.26 environment and...it produced the same new behavior as 2.26 on Windows (so the correct behavior, per the documented changes). At that point I dug further into our builds and found that while we were using the right Git version, we _weren't_ running all the same tests on Linux and Windows. So the successful build on Linux was not because the tests pass--I've adjusted the builds and confirmed that the tests _don't_ pass--but rather because the relevant tests weren't being run at all. Very sorry for wasting your time, Elijah. I should have looked into our builds more closely to verify they were running the same tests before I took the question to the list. Best regards, Bryan Turner
