{"thread":{"id":"57711","subject":"git-bisect behaves differently when started in equivalent ways","startedAt":"2022-04-11T14:48:26Z","lastAt":"2022-04-13T08:37:29Z","messageCount":2,"participants":["Christoph Groth","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"453411","messageId":"878rsbof6v.fsf@drac","threadId":"57711","inReplyTo":null,"subject":"git-bisect behaves differently when started in equivalent ways","fromName":"Christoph Groth","fromEmail":"christoph@grothesque.org","sentAt":"2022-04-11T14:41:28Z","receivedAt":"2022-04-11T14:48:26Z","isPatch":false,"sender":{"key":"christoph@grothesque.org","avatar":null},"body":"Hello,\n\nI found a puzzling behavior with git-bisect for which I was unable to\nfind any explanation.  Since this might be a bug, I report it here.\n\ncheers\nChristoph\n\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\nWhile bisecting a regression caused by a backwards-incompatible change\nin the sympy project, I noticed that “git bisect” can behave\ndifferently when started in different but supposedly equivalent ways.\n\nThe following complete log demonstrates the issue.\n\nFor the first run, I clone the “sympy” repository and start bisect with\n“git bisect start” (as shown in the first example of the git bisect\nmanpage).  I declare a good and a bad commit and am asked to estimate\na specific commit.  I declare this one to be good (which it is for my\nparticular problem), but this causes git to remark that a commit is\n“both good and bad”.\n\nFor the second run, I provide the bad and the good commit to git-bisect\nstart right away.  I am asked to examine the same commit as before to\nwhich I give the same assessment.  This time, git-bisect accepts this.\n\n# Preparation\n/tmp% git clone https://github.com/sympy/sympy.git\nCloning into 'sympy'...\n(...)\n/tmp% cd sympy \n/tmp/sympy% git checkout sympy-1.7.1\nNote: switching to 'sympy-1.7.1'.\n(...)\nHEAD is now at 9e8f62e059 Merge pull request #20592 from oscarbenjamin/pr_latex_filename\n\n# First run\n/tmp/sympy% git bisect start\n/tmp/sympy% git bisect good\n/tmp/sympy% git bisect bad sympy-1.10.1\nBisecting: a merge base must be tested\n[da03c3227771953b0dd175b5b2ef65ebb937b0df] Merge pull request #20228 from sidhu1012/perf\n/tmp/sympy% git describe\nsympy-1.6-2010-gda03c32277\n/tmp/sympy% git bisect good\nf5bba2a7147ef8a6980ff043e93dd038c14bb9bc was both good and bad\n\n# Second run\n/tmp/sympy% git bisect reset\nPrevious HEAD position was da03c32277 Merge pull request #20228 from sidhu1012/perf\nHEAD is now at 9e8f62e059 Merge pull request #20592 from oscarbenjamin/pr_latex_filename\n/tmp/sympy% git bisect start sympy-1.10.1 sympy-1.7.1\nBisecting: a merge base must be tested\n[da03c3227771953b0dd175b5b2ef65ebb937b0df] Merge pull request #20228 from sidhu1012/perf\n/tmp/sympy% git describe\nsympy-1.6-2010-gda03c32277\n/tmp/sympy% git bisect good\nBisecting: 2606 revisions left to test after this (roughly 11 steps)\n[b335cf582f4a789b725cc37822d6eed42c8d9e71] add test and fix space\n\nWhat did you expect to happen? (Expected behavior)\n\nI expected git-bisect to behave in the same way both times.\n\nWhat happened instead? (Actual behavior)\n\nOne time it complains that a commit is “both good and bad”, one time it\ndoes not.\n\nAnything else you want to add:\n\nI could not find any explanation for the difference.  If it is\nintentional I suggest documenting it more clearly.\n\n\n[System Info]\ngit version:\ngit version 2.30.2\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64\ncompiler info: gnuc: 10.2\nlibc info: glibc: 2.31\n$SHELL (typically, interactive shell): /bin/zsh\n\n\n[Enabled Hooks]\n"},{"id":"453474","messageId":"CAP8UFD3zZuik9VkrTLivOTjK5GWJ1kEO3hNFN-18t12OFq7Org@mail.gmail.com","threadId":"57711","inReplyTo":"878rsbof6v.fsf@drac","subject":"Re: git-bisect behaves differently when started in equivalent ways","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2022-04-13T08:37:12Z","receivedAt":"2022-04-13T08:37:29Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Tue, Apr 12, 2022 at 9:51 PM Christoph Groth\n<christoph@grothesque.org> wrote:\n\n> I found a puzzling behavior with git-bisect for which I was unable to\n> find any explanation.  Since this might be a bug, I report it here.\n\nThanks for reporting this strange behavior.\n\nUnfortunately when trying to reproduce, I don't get\n\"f5bba2a7147ef8a6980ff043e93dd038c14bb9bc was both good and bad\" like\nyou, but the expected:\n\nBisecting: 2606 revisions left to test after this (roughly 11 steps)\n[b335cf582f4a789b725cc37822d6eed42c8d9e71] add test and fix space\n\nYou are using Git 2.30.2 which is one year old. Could you try with a\nmore recent version like 2.35.1?\n\nBest,\nChristian.\n"}]}