{"thread":{"id":"61662","subject":"Git bisect skip","startedAt":"2024-06-21T04:01:28Z","lastAt":"2024-06-25T04:45:01Z","messageCount":5,"participants":["Michael Gofron","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"497447","messageId":"968676664.8436621.1718941871973@mail.yahoo.com","threadId":"61662","inReplyTo":"968676664.8436621.1718941871973.ref@mail.yahoo.com","subject":"Git bisect skip","fromName":"Michael Gofron","fromEmail":"gofronm@yahoo.com","sentAt":"2024-06-21T03:51:11Z","receivedAt":"2024-06-21T04:01:28Z","isPatch":false,"sender":{"key":"gofronm@yahoo.com","avatar":null},"body":"Hello,\n\nMy question is can using `git bisect skip` cause a bisect to be indeterminate and/or fail if the commits that are skipped couldn't have caused the issue? \n\nConsider if my commits are like this:\n\n1P - 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F. \nP for \"Pass\", B for \"Broken\", and F for \"Fail\". \nBroken commits are commits that we can't create a build for but wouldn't cause the issue.\nFailing commits are failing because of a bug. \n\nIn this case, 8F caused the bug.\nIf you tell git bisect that 1P is good and 9F is bad, bisect picks a commit between the known newest Good commit (1P) and the known oldest Bad commit (9F).\n\n1P -- 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F\nG                                        B\n      <------------------------------>\nPerhaps 4P. That builds and passes, so it marks that as Good.\n\nIf it then goes to 6B which is a Broken commit and we do `git bisect skip` what happens next? It seems from the code it uses a psuedo random number generator with bias to determine the next commit. Would it ever get in a state where it can't determine the commit that caused the issue even if these broken commits would never cause an issue? \n\n-Thank you\nMichael Gofron\n"},{"id":"497471","messageId":"CAP8UFD2mX+6f0TX4M2YKGC0v4rqR-Ng6syJzBDdtDZX93HF7zQ@mail.gmail.com","threadId":"61662","inReplyTo":"968676664.8436621.1718941871973@mail.yahoo.com","subject":"Re: Git bisect skip","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-06-21T07:37:50Z","receivedAt":"2024-06-21T07:38:05Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Fri, Jun 21, 2024 at 6:01 AM Michael Gofron wrote:\n>\n> Hello,\n>\n> My question is can using `git bisect skip` cause a bisect to be indeterminate and/or fail if the commits that are skipped couldn't have caused the issue?\n\nIf some skipped commits haven't caused the issue but they are direct\nancestors of the commit that caused the issue, then git bisect might\nnot be able to tell which one among those commits and the commit that\ncaused the issue is the actual commit that caused the issue.\n\nFor example if there is the following history:\n\nG1-S1-G2-G3-S2-S3-B1-S4-S5-B2-B3-S6\n\n(where G* are \"good\" commits, S* are skipped commits and B* are \"bad\"\ncommits) then git bisect will not be able to determine which one is\nthe first bad commit between S2, S3 and B1.\n\n> Consider if my commits are like this:\n>\n> 1P - 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F.\n> P for \"Pass\", B for \"Broken\", and F for \"Fail\".\n> Broken commits are commits that we can't create a build for but wouldn't cause the issue.\n> Failing commits are failing because of a bug.\n\nSimilarly as the case above, I would say that git bisect will not be\nable to determine which one is the first bad between 6B, 7B and 8F.\n\n> In this case, 8F caused the bug.\n> If you tell git bisect that 1P is good and 9F is bad, bisect picks a commit between the known newest Good commit (1P) and the known oldest Bad commit (9F).\n\nYeah, it should pick one in the middle, so likely 4P, 5P or 6B.\n\n> 1P -- 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F\n> G B\n> <------------------------------>\n> Perhaps 4P. That builds and passes, so it marks that as Good.\n>\n> If it then goes to 6B which is a Broken commit and we do `git bisect skip` what happens next? It seems from the code it uses a psuedo random number generator with bias to determine the next commit.\n\nYeah, because it tries to avoid testing broken commits that are likely\nto be around the broken commit it already picked, while at the same\ntime it tries to be efficient which means to pick a commit near the\nmiddle of the range of commits left.\n\n> Would it ever get in a state where it can't determine the commit that caused the issue even if these broken commits would never cause an issue?\n\nIt can't know that the broken commits that are direct ancestors of a\n\"bad\" (or \"failed\" commit as you call them) would never cause the\nissue, so it should eventually say that it can't determine which\ncommit is the first bad commit among 6B, 7B and 8F.\n\nIf you are sure that some broken commits don't have the issue you can\nmark them as \"good\" to help git bisect which should then be able to\nfind the first \"bad\" commit.\n\nBest,\nChristian.\n"},{"id":"497525","messageId":"1323275190.8859033.1719006830207@mail.yahoo.com","threadId":"61662","inReplyTo":"CAP8UFD2mX+6f0TX4M2YKGC0v4rqR-Ng6syJzBDdtDZX93HF7zQ@mail.gmail.com","subject":"Re: Git bisect skip","fromName":"Michael Gofron","fromEmail":"gofronm@yahoo.com","sentAt":"2024-06-21T21:53:50Z","receivedAt":"2024-06-21T22:04:01Z","isPatch":false,"sender":{"key":"gofronm@yahoo.com","avatar":null},"body":"Thank you. This was very detailed. \n\nAnother question I have is does the exclude filepath include commits which have changes in the excluded filepaths and in the included filepaths? \n\nI noticed for instance I could specify to include and exclude changes to certain files with a format like the following: \n\n`git bisect start bad_commit good_commit -- 'mobile/' ':!mobile/tests.yaml' ':!mobile/GeneratedSources``\n\nThe includes filepath is any changes in `mobile` and the exclude is changes in `mobile/tests.yaml` and `mobile/GeneratedSources`. \n\nIn the prior example, I'd like to ignore commits where the only changes are in `mobile/tests.yaml` and/or `mobile/GeneratedSources`. If there were a change in `mobile/tests.yaml` and a change in say `mobile/highly_important_fragile_code.swift` would it include that in the bisect? \n\n-Thank you\nMichael Gofron\n\n\n\n\n\n\nOn Friday, June 21, 2024 at 04:38:05 PM GMT+9, Christian Couder wrote: \n\n\n\n\n\nHi,\n\nOn Fri, Jun 21, 2024 at 6:01 AM Michael Gofron wrote:\n>\n> Hello,\n>\n> My question is can using `git bisect skip` cause a bisect to be indeterminate and/or fail if the commits that are skipped couldn't have caused the issue?\n\nIf some skipped commits haven't caused the issue but they are direct\nancestors of the commit that caused the issue, then git bisect might\nnot be able to tell which one among those commits and the commit that\ncaused the issue is the actual commit that caused the issue.\n\nFor example if there is the following history:\n\nG1-S1-G2-G3-S2-S3-B1-S4-S5-B2-B3-S6\n\n(where G* are \"good\" commits, S* are skipped commits and B* are \"bad\"\ncommits) then git bisect will not be able to determine which one is\nthe first bad commit between S2, S3 and B1.\n\n> Consider if my commits are like this:\n>\n> 1P - 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F.\n> P for \"Pass\", B for \"Broken\", and F for \"Fail\".\n> Broken commits are commits that we can't create a build for but wouldn't cause the issue.\n> Failing commits are failing because of a bug.\n\nSimilarly as the case above, I would say that git bisect will not be\nable to determine which one is the first bad between 6B, 7B and 8F.\n\n> In this case, 8F caused the bug.\n> If you tell git bisect that 1P is good and 9F is bad, bisect picks a commit between the known newest Good commit (1P) and the known oldest Bad commit (9F).\n\nYeah, it should pick one in the middle, so likely 4P, 5P or 6B.\n\n> 1P -- 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F\n> G                                        B\n>      <------------------------------>\n> Perhaps 4P. That builds and passes, so it marks that as Good.\n>\n> If it then goes to 6B which is a Broken commit and we do `git bisect skip` what happens next? It seems from the code it uses a psuedo random number generator with bias to determine the next commit.\n\nYeah, because it tries to avoid testing broken commits that are likely\nto be around the broken commit it already picked, while at the same\ntime it tries to be efficient which means to pick a commit near the\nmiddle of the range of commits left.\n\n\n> Would it ever get in a state where it can't determine the commit that caused the issue even if these broken commits would never cause an issue?\n\n\nIt can't know that the broken commits that are direct ancestors of a\n\"bad\" (or \"failed\" commit as you call them) would never cause the\nissue, so it should eventually say that it can't determine which\ncommit is the first bad commit among 6B, 7B and 8F.\n\nIf you are sure that some broken commits don't have the issue you can\nmark them as \"good\" to help git bisect which should then be able to\nfind the first \"bad\" commit.\n\nBest,\nChristian.\n\n"},{"id":"497601","messageId":"1824627947.974283.1719289765885@mail.yahoo.com","threadId":"61662","inReplyTo":"156587144.9842852.1719288870477@mail.yahoo.com","subject":"Re: Git bisect skip","fromName":"Michael Gofron","fromEmail":"gofronm@yahoo.com","sentAt":"2024-06-25T04:29:25Z","receivedAt":"2024-06-25T04:29:37Z","isPatch":false,"sender":{"key":"gofronm@yahoo.com","avatar":null},"body":"To add to that I had another question: \n\n1. Is there a way to preview the next commit that bisect would pick if it were a good commit, a bad commit, or a skipped commit? \n\n-Thank you\n\n\n\n\n\n\nOn Tuesday, June 25, 2024 at 01:14:30 PM GMT+9, Michael Gofron wrote: \n\n\n\n\n\nI ended up testing out the filepath exclusion with a test repo I'd set up with mock data. \n\nI have two more questions regarding bisect:\n\n1. Is there a way to specify regex with regard to the filepath spec? So I could specify something like `git bisect start bad_commit good_commit ':!*.md'` to avoid changes that only happen in `.md` documentation files? I had tested locally in my git test repo I'd set up and couldn't seem to find a way filter changes with a regex or file extensions rather than specific paths. \n2. Is there a way to check the contents of files and exclude based off a script if the file was changed in a particular way? In my case, I had been thinking if a file only added comments to avoid testing that specific commit.\n\n-Thank you\nMichael Gofron\n\n\n\n\n\n\nOn Saturday, June 22, 2024 at 06:53:50 AM GMT+9, Michael Gofron wrote: \n\n\n\n\n\nThank you. This was very detailed. \n\nAnother question I have is does the exclude filepath include commits which have changes in the excluded filepaths and in the included filepaths? \n\nI noticed for instance I could specify to include and exclude changes to certain files with a format like the following: \n\n`git bisect start bad_commit good_commit -- 'mobile/' ':!mobile/tests.yaml' ':!mobile/GeneratedSources``\n\nThe includes filepath is any changes in `mobile` and the exclude is changes in `mobile/tests.yaml` and `mobile/GeneratedSources`. \n\nIn the prior example, I'd like to ignore commits where the only changes are in `mobile/tests.yaml` and/or `mobile/GeneratedSources`. If there were a change in `mobile/tests.yaml` and a change in say `mobile/highly_important_fragile_code.swift` would it include that in the bisect? \n\n-Thank you\nMichael Gofron\n\n\n\n\n\n\nOn Friday, June 21, 2024 at 04:38:05 PM GMT+9, Christian Couder wrote: \n\n\n\n\n\nHi,\n\nOn Fri, Jun 21, 2024 at 6:01 AM Michael Gofron wrote:\n>\n> Hello,\n>\n> My question is can using `git bisect skip` cause a bisect to be indeterminate and/or fail if the commits that are skipped couldn't have caused the issue?\n\nIf some skipped commits haven't caused the issue but they are direct\nancestors of the commit that caused the issue, then git bisect might\nnot be able to tell which one among those commits and the commit that\ncaused the issue is the actual commit that caused the issue.\n\nFor example if there is the following history:\n\nG1-S1-G2-G3-S2-S3-B1-S4-S5-B2-B3-S6\n\n(where G* are \"good\" commits, S* are skipped commits and B* are \"bad\"\ncommits) then git bisect will not be able to determine which one is\nthe first bad commit between S2, S3 and B1.\n\n> Consider if my commits are like this:\n>\n> 1P - 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F.\n> P for \"Pass\", B for \"Broken\", and F for \"Fail\".\n> Broken commits are commits that we can't create a build for but wouldn't cause the issue.\n> Failing commits are failing because of a bug.\n\nSimilarly as the case above, I would say that git bisect will not be\nable to determine which one is the first bad between 6B, 7B and 8F.\n\n> In this case, 8F caused the bug.\n> If you tell git bisect that 1P is good and 9F is bad, bisect picks a commit between the known newest Good commit (1P) and the known oldest Bad commit (9F).\n\nYeah, it should pick one in the middle, so likely 4P, 5P or 6B.\n\n> 1P -- 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F\n> G                                        B\n>      <------------------------------>\n> Perhaps 4P. That builds and passes, so it marks that as Good.\n>\n> If it then goes to 6B which is a Broken commit and we do `git bisect skip` what happens next? It seems from the code it uses a psuedo random number generator with bias to determine the next commit.\n\nYeah, because it tries to avoid testing broken commits that are likely\nto be around the broken commit it already picked, while at the same\ntime it tries to be efficient which means to pick a commit near the\nmiddle of the range of commits left.\n\n\n> Would it ever get in a state where it can't determine the commit that caused the issue even if these broken commits would never cause an issue?\n\n\nIt can't know that the broken commits that are direct ancestors of a\n\"bad\" (or \"failed\" commit as you call them) would never cause the\nissue, so it should eventually say that it can't determine which\ncommit is the first bad commit among 6B, 7B and 8F.\n\nIf you are sure that some broken commits don't have the issue you can\nmark them as \"good\" to help git bisect which should then be able to\nfind the first \"bad\" commit.\n\nBest,\nChristian.\n\n"},{"id":"497602","messageId":"156587144.9842852.1719288870477@mail.yahoo.com","threadId":"61662","inReplyTo":"1323275190.8859033.1719006830207@mail.yahoo.com","subject":"Re: Git bisect skip","fromName":"Michael Gofron","fromEmail":"gofronm@yahoo.com","sentAt":"2024-06-25T04:14:30Z","receivedAt":"2024-06-25T04:45:01Z","isPatch":false,"sender":{"key":"gofronm@yahoo.com","avatar":null},"body":"I ended up testing out the filepath exclusion with a test repo I'd set up with mock data. \n\nI have two more questions regarding bisect:\n\n1. Is there a way to specify regex with regard to the filepath spec? So I could specify something like `git bisect start bad_commit good_commit ':!*.md'` to avoid changes that only happen in `.md` documentation files? I had tested locally in my git test repo I'd set up and couldn't seem to find a way filter changes with a regex or file extensions rather than specific paths. \n2. Is there a way to check the contents of files and exclude based off a script if the file was changed in a particular way? In my case, I had been thinking if a file only added comments to avoid testing that specific commit.\n\n-Thank you\nMichael Gofron\n\n\n\n\n\n\nOn Saturday, June 22, 2024 at 06:53:50 AM GMT+9, Michael Gofron wrote: \n\n\n\n\n\nThank you. This was very detailed. \n\nAnother question I have is does the exclude filepath include commits which have changes in the excluded filepaths and in the included filepaths? \n\nI noticed for instance I could specify to include and exclude changes to certain files with a format like the following: \n\n`git bisect start bad_commit good_commit -- 'mobile/' ':!mobile/tests.yaml' ':!mobile/GeneratedSources``\n\nThe includes filepath is any changes in `mobile` and the exclude is changes in `mobile/tests.yaml` and `mobile/GeneratedSources`. \n\nIn the prior example, I'd like to ignore commits where the only changes are in `mobile/tests.yaml` and/or `mobile/GeneratedSources`. If there were a change in `mobile/tests.yaml` and a change in say `mobile/highly_important_fragile_code.swift` would it include that in the bisect? \n\n-Thank you\nMichael Gofron\n\n\n\n\n\n\nOn Friday, June 21, 2024 at 04:38:05 PM GMT+9, Christian Couder wrote: \n\n\n\n\n\nHi,\n\nOn Fri, Jun 21, 2024 at 6:01 AM Michael Gofron wrote:\n>\n> Hello,\n>\n> My question is can using `git bisect skip` cause a bisect to be indeterminate and/or fail if the commits that are skipped couldn't have caused the issue?\n\nIf some skipped commits haven't caused the issue but they are direct\nancestors of the commit that caused the issue, then git bisect might\nnot be able to tell which one among those commits and the commit that\ncaused the issue is the actual commit that caused the issue.\n\nFor example if there is the following history:\n\nG1-S1-G2-G3-S2-S3-B1-S4-S5-B2-B3-S6\n\n(where G* are \"good\" commits, S* are skipped commits and B* are \"bad\"\ncommits) then git bisect will not be able to determine which one is\nthe first bad commit between S2, S3 and B1.\n\n> Consider if my commits are like this:\n>\n> 1P - 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F.\n> P for \"Pass\", B for \"Broken\", and F for \"Fail\".\n> Broken commits are commits that we can't create a build for but wouldn't cause the issue.\n> Failing commits are failing because of a bug.\n\nSimilarly as the case above, I would say that git bisect will not be\nable to determine which one is the first bad between 6B, 7B and 8F.\n\n> In this case, 8F caused the bug.\n> If you tell git bisect that 1P is good and 9F is bad, bisect picks a commit between the known newest Good commit (1P) and the known oldest Bad commit (9F).\n\nYeah, it should pick one in the middle, so likely 4P, 5P or 6B.\n\n> 1P -- 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F\n> G                                        B\n>      <------------------------------>\n> Perhaps 4P. That builds and passes, so it marks that as Good.\n>\n> If it then goes to 6B which is a Broken commit and we do `git bisect skip` what happens next? It seems from the code it uses a psuedo random number generator with bias to determine the next commit.\n\nYeah, because it tries to avoid testing broken commits that are likely\nto be around the broken commit it already picked, while at the same\ntime it tries to be efficient which means to pick a commit near the\nmiddle of the range of commits left.\n\n\n> Would it ever get in a state where it can't determine the commit that caused the issue even if these broken commits would never cause an issue?\n\n\nIt can't know that the broken commits that are direct ancestors of a\n\"bad\" (or \"failed\" commit as you call them) would never cause the\nissue, so it should eventually say that it can't determine which\ncommit is the first bad commit among 6B, 7B and 8F.\n\nIf you are sure that some broken commits don't have the issue you can\nmark them as \"good\" to help git bisect which should then be able to\nfind the first \"bad\" commit.\n\nBest,\nChristian.\n\n"}]}