{"thread":{"id":"53148","subject":"Rebase-via-merge behavior difference between Linux and Windows","startedAt":"2020-03-31T23:24:42Z","lastAt":"2020-04-02T03:02:47Z","messageCount":4,"participants":["Bryan Turner","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"394448","messageId":"CAGyf7-FUjCefwGjvCcwmjO=GADd5S0cU_=S_tVy4nMaj07+rQA@mail.gmail.com","threadId":"53148","inReplyTo":null,"subject":"Rebase-via-merge behavior difference between Linux and Windows","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2020-03-31T23:24:28Z","receivedAt":"2020-03-31T23:24:42Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"With the default rebase backend changing from \"apply\" to \"merge\" in\n2.26, I've seen several threads about behavior changes between the two\nbackends. This is _not_ one of those (although, as I mention at the\nend, the \"apply\" backend doesn't appear to have this issue).\n\nInstead, what I'm observing is a behavior difference between the same\n\"merge\" backend depending on whether the command is run on Linux or\nWindows.\n\nA little context: Bitbucket Server has a set of zipped repositories\nthat provide consistent initial state, and we have tests that download\nthose zips and then run various Git commands against them and verify\nwe get expected outcomes. These same tests run on both Windows and\nLinux.\n\nUsing our merge test repository[1], one such test performs the following steps:\n* Unzip bare repository\n* `git clone --shared -b branch_that_differ_by_empty_commit_trgt\n<unzipped> rebase-test`\n* `git rebase -q --no-verify 7549846524f8aed2bd1c0249993ae1bf9d3c9998\n298924b8c403240eaf89dcda0cce7271620ab2f6`\n\n298924b8c40 is an empty commit (i.e. `git commit --allow-empty`), and\nis the only commit not already reachable from 7549846524f.\n\nOn Linux, when this test completes, \"HEAD\" in \"rebase-test\" is\n7549846524f because the empty commit was discarded. This is the\nexpected behavior. On Windows, \"HEAD\" is a new empty commit, which\ncauses our test to fail.\n\nIf I set \"rebase.backend=apply\" on the \"git rebase\" command, I once\nagain get identical behavior on both platforms, with the empty commit\ndiscarded. (I'm just noting this in case it's relevant.)\n\n[1] https://packages.atlassian.com/maven-public-local/com/atlassian/stash/git/merge/2.9/merge-2.9.zip\n"},{"id":"394467","messageId":"CABPp-BFDx2j5Kf584Myb6wuEq5G7wbogJ2vos8OTDsh+ySfk8w@mail.gmail.com","threadId":"53148","inReplyTo":"CAGyf7-FUjCefwGjvCcwmjO=GADd5S0cU_=S_tVy4nMaj07+rQA@mail.gmail.com","subject":"Re: Rebase-via-merge behavior difference between Linux and Windows","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-04-01T06:35:44Z","receivedAt":"2020-04-01T06:35:57Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Mar 31, 2020 at 4:25 PM Bryan Turner <bturner@atlassian.com> wrote:\n>\n> With the default rebase backend changing from \"apply\" to \"merge\" in\n> 2.26, I've seen several threads about behavior changes between the two\n> backends. This is _not_ one of those (although, as I mention at the\n> end, the \"apply\" backend doesn't appear to have this issue).\n>\n> Instead, what I'm observing is a behavior difference between the same\n> \"merge\" backend depending on whether the command is run on Linux or\n> Windows.\n>\n> A little context: Bitbucket Server has a set of zipped repositories\n> that provide consistent initial state, and we have tests that download\n> those zips and then run various Git commands against them and verify\n> we get expected outcomes. These same tests run on both Windows and\n> Linux.\n>\n> Using our merge test repository[1], one such test performs the following steps:\n> * Unzip bare repository\n> * `git clone --shared -b branch_that_differ_by_empty_commit_trgt\n> <unzipped> rebase-test`\n> * `git rebase -q --no-verify 7549846524f8aed2bd1c0249993ae1bf9d3c9998\n> 298924b8c403240eaf89dcda0cce7271620ab2f6`\n>\n> 298924b8c40 is an empty commit (i.e. `git commit --allow-empty`), and\n> is the only commit not already reachable from 7549846524f.\n>\n> On Linux, when this test completes, \"HEAD\" in \"rebase-test\" is\n> 7549846524f because the empty commit was discarded. This is the\n> expected behavior. On Windows, \"HEAD\" is a new empty commit, which\n> causes our test to fail.\n\nI don't have a Windows box to test, but it's good that you are seeing\nthe correct behavior there.  I do have a Linux box, and cannot\nduplicate the behavior you state, even downloading the zip you\nmentioned and following your steps to reproduce.  Actually, I did\nreproduce that behavior the first time because I was accidentally\nusing git-2.25.0.  But with git-2.26.0 on Linux, I see a new empty\ncommit after rebasing, as expected.\n\nIs there any chance you accidentally ran with an older git version\nwhen on Linux?  If you really were using git 2.26.0 on Linux...then\nI'm totally confused at how you got that behavior.\n\nAnd yes, I am stating the exact opposite expectation than what you\ndid; let me quote from the relevant bits of the 2.26.0 manpage for git\nrebase:\n\nBEHAVIORAL DIFFERENCES\n-----------------------\n...\nEmpty commits\n~~~~~~~~~~~~~\n\nThe apply backend unfortunately drops intentionally empty commits, i.e.\ncommits that started empty, though these are rare in practice.  It\nalso drops commits that become empty and has no option for controlling\nthis behavior.\n\nThe merge backend keeps intentionally empty commits.  Similar to the\napply backend, by default the merge backend drops commits that become\nempty unless -i/--interactive is specified (in which case it stops and\nasks the user what to do).  The merge backend also has an\n--empty={drop,keep,ask} option for changing the behavior of handling\ncommits that become empty.\n\n\nSo the apply backend has the wrong behavior, we just haven't bothered\nupdating it.  Perhaps we should.\n"},{"id":"394539","messageId":"CAGyf7-FTNOgDbWEoniaOWueWGXwH6=0gj_FzDqP35422vxhYEA@mail.gmail.com","threadId":"53148","inReplyTo":"CABPp-BFDx2j5Kf584Myb6wuEq5G7wbogJ2vos8OTDsh+ySfk8w@mail.gmail.com","subject":"Re: Rebase-via-merge behavior difference between Linux and Windows","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2020-04-02T01:15:49Z","receivedAt":"2020-04-02T01:16:08Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Tue, Mar 31, 2020 at 11:35 PM Elijah Newren <newren@gmail.com> wrote:\n>\n> On Tue, Mar 31, 2020 at 4:25 PM Bryan Turner <bturner@atlassian.com> wrote:\n> >\n> > Using our merge test repository[1], one such test performs the following steps:\n> > * Unzip bare repository\n> > * `git clone --shared -b branch_that_differ_by_empty_commit_trgt\n> > <unzipped> rebase-test`\n> > * `git rebase -q --no-verify 7549846524f8aed2bd1c0249993ae1bf9d3c9998\n> > 298924b8c403240eaf89dcda0cce7271620ab2f6`\n> >\n> > 298924b8c40 is an empty commit (i.e. `git commit --allow-empty`), and\n> > is the only commit not already reachable from 7549846524f.\n> >\n> > On Linux, when this test completes, \"HEAD\" in \"rebase-test\" is\n> > 7549846524f because the empty commit was discarded. This is the\n> > expected behavior. On Windows, \"HEAD\" is a new empty commit, which\n> > causes our test to fail.\n>\n> I don't have a Windows box to test, but it's good that you are seeing\n> the correct behavior there.  I do have a Linux box, and cannot\n> duplicate the behavior you state, even downloading the zip you\n> mentioned and following your steps to reproduce.  Actually, I did\n> reproduce that behavior the first time because I was accidentally\n> using git-2.25.0.  But with git-2.26.0 on Linux, I see a new empty\n> commit after rebasing, as expected.\n>\n> Is there any chance you accidentally ran with an older git version\n> when on Linux?  If you really were using git 2.26.0 on Linux...then\n> I'm totally confused at how you got that behavior.\n\nI went back through our build logs and confirmed that we _are_ running\nGit 2.26 (phew). I then set up a local Git 2.26 environment and...it\nproduced the same new behavior as 2.26 on Windows (so the correct\nbehavior, per the documented changes).\n\nAt that point I dug further into our builds and found that while we\nwere using the right Git version, we _weren't_ running all the same\ntests on Linux and Windows. So the successful build on Linux was not\nbecause the tests pass--I've adjusted the builds and confirmed that\nthe tests _don't_ pass--but rather because the relevant tests weren't\nbeing run at all.\n\nVery sorry for wasting your time, Elijah. I should have looked into\nour builds more closely to verify they were running the same tests\nbefore I took the question to the list.\n\nBest regards,\nBryan Turner\n"},{"id":"394542","messageId":"CABPp-BEYqmU76yqnaC3AdgACpfWeCCytX_ixnB94xQk_4KnK_w@mail.gmail.com","threadId":"53148","inReplyTo":"CAGyf7-FTNOgDbWEoniaOWueWGXwH6=0gj_FzDqP35422vxhYEA@mail.gmail.com","subject":"Re: Rebase-via-merge behavior difference between Linux and Windows","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-04-02T03:02:34Z","receivedAt":"2020-04-02T03:02:47Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Bryan,\n\nOn Wed, Apr 1, 2020 at 6:16 PM Bryan Turner <bturner@atlassian.com> wrote:\n>\n> On Tue, Mar 31, 2020 at 11:35 PM Elijah Newren <newren@gmail.com> wrote:\n> >\n> > On Tue, Mar 31, 2020 at 4:25 PM Bryan Turner <bturner@atlassian.com> wrote:\n> > >\n> > > Using our merge test repository[1], one such test performs the following steps:\n> > > * Unzip bare repository\n> > > * `git clone --shared -b branch_that_differ_by_empty_commit_trgt\n> > > <unzipped> rebase-test`\n> > > * `git rebase -q --no-verify 7549846524f8aed2bd1c0249993ae1bf9d3c9998\n> > > 298924b8c403240eaf89dcda0cce7271620ab2f6`\n> > >\n> > > 298924b8c40 is an empty commit (i.e. `git commit --allow-empty`), and\n> > > is the only commit not already reachable from 7549846524f.\n> > >\n> > > On Linux, when this test completes, \"HEAD\" in \"rebase-test\" is\n> > > 7549846524f because the empty commit was discarded. This is the\n> > > expected behavior. On Windows, \"HEAD\" is a new empty commit, which\n> > > causes our test to fail.\n> >\n> > I don't have a Windows box to test, but it's good that you are seeing\n> > the correct behavior there.  I do have a Linux box, and cannot\n> > duplicate the behavior you state, even downloading the zip you\n> > mentioned and following your steps to reproduce.  Actually, I did\n> > reproduce that behavior the first time because I was accidentally\n> > using git-2.25.0.  But with git-2.26.0 on Linux, I see a new empty\n> > commit after rebasing, as expected.\n> >\n> > Is there any chance you accidentally ran with an older git version\n> > when on Linux?  If you really were using git 2.26.0 on Linux...then\n> > I'm totally confused at how you got that behavior.\n>\n> I went back through our build logs and confirmed that we _are_ running\n> Git 2.26 (phew). I then set up a local Git 2.26 environment and...it\n> produced the same new behavior as 2.26 on Windows (so the correct\n> behavior, per the documented changes).\n>\n> At that point I dug further into our builds and found that while we\n> were using the right Git version, we _weren't_ running all the same\n> tests on Linux and Windows. So the successful build on Linux was not\n> because the tests pass--I've adjusted the builds and confirmed that\n> the tests _don't_ pass--but rather because the relevant tests weren't\n> being run at all.\n>\n> Very sorry for wasting your time, Elijah. I should have looked into\n> our builds more closely to verify they were running the same tests\n> before I took the question to the list.\n\nHey, no worries; you provide good comments on the list and it was\nreally nice that your report came with very detailed steps to follow,\nso it ended up not taking that long to check.  Thanks for double\nchecking to verify that I wasn't insane (or at least that this one\nissue doesn't prove I am).  Anyway, not a big deal at all; keep\nreporting potential issues you run across in the future.\n\nElijah\n"}]}