{"thread":{"id":"26725","subject":"git bisect plus fixes (was: PATCH: Add --size-check=[error|warning])","startedAt":"2011-03-14T13:16:23Z","lastAt":"2011-03-16T20:35:01Z","messageCount":10,"participants":["Ralf Wildenhues","Michael J Gruber","Junio C Hamano","Yann Dirson","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"163305","messageId":"20110314131623.119020@gmx.net","threadId":"26725","inReplyTo":"20110314122342.GA26825@elte.hu","subject":"git bisect plus fixes (was: PATCH: Add --size-check=[error|warning])","fromName":"Ralf Wildenhues","fromEmail":"ralf.wildenhues@gmx.de","sentAt":"2011-03-14T13:16:23Z","receivedAt":"2011-03-14T13:16:23Z","isPatch":false,"sender":{"key":"ralf.wildenhues@gmx.de","avatar":null},"body":"[ adding the git list; this is\n  http://thread.gmane.org/gmane.comp.gnu.binutils/52601/focus=1112779 ]\n\nHello,\n\n* Ingo Molnar wrote on Mon, Mar 14, 2011 at 01:23:42PM CET:\n> Also, i hope you are not suggesting to break projects just because\n> they are not important to you personally? The fix is exceedingly\n> simple to do for the binutils project - and impossible to do for the\n> kernel project (because during bisection - which is a very powerful\n> debugging tool - older versions of the source get checked out).\n\nFWIW, I don't have an opinion on this particular binutils issue, but\nit would be very helpful if 'git bisect' made it easy to denote\n\"when going back, you might also need some of these changes\".\n(I'd just use a patch -p1 with a here-file in the bisect script, but\nthat might not be enough for all practical use cases.)\n\nThis issue has come up several times with high-profile issues.\n\nThanks,\nRalf\n"},{"id":"163307","messageId":"cf85600a90cea6a0a751c674b821d17d85f34c66.1300109828.git.git@drmicha.warpmail.net","threadId":"26725","inReplyTo":"20110314131623.119020@gmx.net","subject":"[PATCH] git-bisect.txt: example for bisecting with hotfix","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-14T13:47:20Z","receivedAt":"2011-03-14T13:47:20Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Give an example on how to bisect when older revisions need a hotfix to\nbuild, run or test. Triggered by the binutils/kernel issue at\n\nhttp://thread.gmane.org/gmane.comp.gnu.binutils/52601/focus=1112779\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\nMaybe this doc fix would do. Just tag the hotfix and tell people to cherry-pick it\nlike this. I don't think \"git bisect --with-fix=hotfix\" would be much simpler.\n(culling kernel list from cc - don't apply this to the wrong tree :)\n\n Documentation/git-bisect.txt |   11 +++++++++++\n 1 files changed, 11 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex c39d957..25acf26 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -322,6 +322,17 @@ $ git bisect run sh -c \"make || exit 125; ~/check_test_case.sh\"\n +\n Does the same as the previous example, but on a single line.\n \n+* Bisect with compatibility hotfix:\n++\n+------------\n+$ git bisect start HEAD HEAD~10 --   # culprit is among the last 10\n+$ git bisect run sh -c \"git cherry-pick -n hotfix || exit 125; make || exit 125; ~/check_test_case.sh\"\n+------------\n++\n+Does the same as the previous example, but applies an additional patch\n+before building. This is useful when your build or test environment changed so\n+that older revisions may need a fix which newer ones have already.\n+\n Author\n ------\n Written by Linus Torvalds <torvalds@osdl.org>\n-- \n1.7.4.1.404.g62d316\n"},{"id":"163320","messageId":"7vy64hehbh.fsf@alter.siamese.dyndns.org","threadId":"26725","inReplyTo":"cf85600a90cea6a0a751c674b821d17d85f34c66.1300109828.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] git-bisect.txt: example for bisecting with hotfix","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-14T17:35:14Z","receivedAt":"2011-03-14T17:35:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> +* Bisect with compatibility hotfix:\n> ++\n> +------------\n> +$ git bisect start HEAD HEAD~10 --   # culprit is among the last 10\n> +$ git bisect run sh -c \"git cherry-pick -n hotfix || exit 125; make || exit 125; ~/check_test_case.sh\"\n> +------------\n> ++\n> +Does the same as the previous example, but applies an additional patch\n> +before building. This is useful when your build or test environment changed so\n> +that older revisions may need a fix which newer ones have already.\n> +\n\nIt is a good idea to add an example that shows it is perfectly Ok to muck\nwith the working tree before testing, but I don't see this patch as such.\n\nFirst of all, doesn't bisect_checkout does its job with \"checkout -q\"\nwithout \"-f\"?  How would that interact with running cherry-pick _every\ntime_ you check commit to be tested out?  In some situations it may work\nOK by accident, but as an example that is likely to be cut&pasted I think\nwe should show a reasonably safer way than this.\n\nThere likely are more than one hot-fixes; it would make more sense to\nillustrate merging a hot-fixes branch using \"git merge --no-commit\" than\nusing cherry-pick.\n\nBut the above are minor; the biggest issue I have with this patch is that\nit breaks the train of thought for people who are reading from top to\nbottom.\n\nLook at what is there currently. It starts simple (single command run via\n\"run\" interface), and demonstrates that anything complex can be easily\nmanaged with a fully-spelled-out \"one test wrapper that builds and then\nruns test\" example, to show the most generic way you can use. It then\nintroduces special exit codes in the script, as that form is easier to\nread than a single command line.\n\nIt then shows, as a final aside, that it isn't strictly required to use a\nwrapper script and you could use \"sh -c\" to wrap that in the command line,\nwhich may be easier to use when (and only when IMO---if you will have\nanything that needs debugging then you are better off with the first\napproach) the command line you use for testing is trivial.\n\nI think a new example you are adding would fit much better in the flow if\nyou replaced the example it refers to as \"the previous example\".  There\nare that \"previous example\" that uses the \"check_test_case.sh\", and the\none before that one that uses \"make test\"; they are duplicates that do not\nadd much value and we would add value by dropping one of them.  It\nprobably is better to remove the \"make test\" one and keep the\n\"check_test_case.sh\" one, as long as you explain \"check_test_case.sh\"\nsufficiently well, because the latter is more generally applicable.\n\nThe new example would fit well as an illustration of what you _could_ have\nin test.sh script when you need to do more elaborate set-up before testing\neach revision, e.g., you tweak the working tree with hotfix before running\n\"make || exit 125\", and clean that up after you tested. The core of the\nnew section would look like this:\n\n\t$ cat test.sh\n\t#!/bin/sh\n\n\t# tweak the working tree by merging the hot-fix branch\n        # and then attempt a build\n\tif\tgit cherry-pick --no-commit hot-fix &&\n        \tmake\n\tthen\n                # run project specific test and report its status\n                ./test.sh\n                status=$?\n\telse\n\t\t# tell the caller this is untestable\n\t\tstatus=125\n\tfi\n\n\t# undo the tweak to allow clean flipping to the next commit\n        git reset --hard\n\n\t# return control\n\texit $status\n"},{"id":"163345","messageId":"20110314210001.GE4586@gmx.de","threadId":"26725","inReplyTo":"20110314131623.119020@gmx.net","subject":"[PATCH] Document 'git bisect fix'.","fromName":"Ralf Wildenhues","fromEmail":"ralf.wildenhues@gmx.de","sentAt":"2011-03-14T21:00:01Z","receivedAt":"2011-03-14T21:00:01Z","isPatch":true,"sender":{"key":"ralf.wildenhues@gmx.de","avatar":null},"body":"git bisect is sometimes less effective than it could be in projects\nwith long-lived but simple bugs (e.g., little-tested configurations).\nRather than skipping vast revision ranges, it might be easier to fix\nthem up from known bugfix branches.\n\n'git bisect fix' teaches bisect about when some known bug was\nintroduced and when it was fixed, so that bisect can merge in\nthe fix when needed into new test candidates.\n---\n\n* Ralf Wildenhues wrote on Mon, Mar 14, 2011 at 02:16:23PM CET:\n> it would be very helpful if 'git bisect' made it easy to denote\n> \"when going back, you might also need some of these changes\".\n\nMerging in a set of bugfix branches (branches with minimal fixes, based\nright off of commits introducing some bug) before testing a particular\ncontender would be a good start.  Of course we don't want some bugfix\nbranch to be merged in if the known bug isn't yet in the current\ncontender, so as to not merge unrelated changes.\n\nCherry-pick things is another option, but the above seems a bit more\ngittish to me, and works well with bugfix branches.  Also, data like\n\"bugzilla X was introduced by C1 and fixed by C2\" is helpful (and\nalready available in some projects) anyway in a semi-automatic fashion.\nYou might even want to version it, or keep it in project meta-data.\n\nIf some bug was fixed by a merge only, the more general notation\n\"f_1 ^b_1 ^b_1' ...\" could apply.\n\nHere's a balloon doc patch to show what I mean.  Comments?\nIs this too unlike how bisect works today?  Too dangerous?\n\nThanks, and please keep me in Cc:,\nRalf\n\n Documentation/git-bisect.txt |   20 ++++++++++++++++++++\n git-bisect.sh                |    4 +++-\n 2 files changed, 23 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex c39d957..9074cb3 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -25,6 +25,7 @@ on the subcommand:\n  git bisect replay <logfile>\n  git bisect log\n  git bisect run <cmd>...\n+ git bisect fix [(<range>|<rev>)...]\n \n This command uses 'git rev-list --bisect' to help drive the\n binary search process to find which change introduced a bug, given an\n@@ -198,6 +199,25 @@ $ git bisect skip v2.5 v2.5..v2.6\n This tells the bisect process that the commits between `v2.5` included\n and `v2.6` included should be skipped.\n \n+Fixing up known bugs\n+~~~~~~~~~~~~~~~~~~~~\n+\n+If many revisions are broken due to some unrelated but known issue that\n+is easily fixed, you might want to prefer fixing it up temporarily.\n+If `<commit1>` introduces a bug fixed by `<commit2>`, instruct bisect\n+to merge the latter before testing a commit that contains the former:\n+\n+------------\n+$ git bisect fix <commit1>..<commit2>\n+------------\n+\n+A single `<commit>` acts as if `<commit>^..<commit>` was specified.\n+Fix statements can be repeated for every known bug, and are valid until\n+the bisection state is cleaned up with reset.\n+\n+Any bisect action that causes a new commit to be chosen will try to merge\n+the needed fixes and fail if they do not merge cleanly.\n+\n \n Cutting down bisection by giving more parameters to bisect start\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex c21e33c..2b137f0 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -1,6 +1,6 @@\n #!/bin/sh\n \n-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'\n+USAGE='[help|start|bad|good|skip|fix|next|reset|visualize|replay|log|run]'\n LONG_USAGE='git bisect help\n         print this long help message.\n git bisect start [<bad> [<good>...]] [--] [<pathspec>...]\n@@ -11,6 +11,8 @@ git bisect good [<rev>...]\n         mark <rev>... known-good revisions.\n git bisect skip [(<rev>|<range>)...]\n         mark <rev>... untestable revisions.\n+git bisect fix [(<c1>..<c2>|<rev>)...]\n+        mark descendants of <c1>/<rev^> as needing fixes <c2>/<rev>.\n git bisect next\n         find next bisection to test and check it out.\n git bisect reset [<commit>]\n-- \n1.7.4.1.231.ge4ce\n"},{"id":"163379","messageId":"20110315111620.73108597@chalon.bertin.fr","threadId":"26725","inReplyTo":"20110314210001.GE4586@gmx.de","subject":"Re: [PATCH] Document 'git bisect fix'.","fromName":"Yann Dirson","fromEmail":"dirson@bertin.fr","sentAt":"2011-03-15T10:16:20Z","receivedAt":"2011-03-15T10:16:20Z","isPatch":true,"sender":{"key":"dirson@bertin.fr","avatar":null},"body":"Hi Ralf,\n\nMaybe you should have made it more obvious that this patch is a RFC\nfor a proposed feature (say, in subject line).\n\n>'git bisect fix' teaches bisect about when some known bug was\n>introduced and when it was fixed, so that bisect can merge in\n>the fix when needed into new test candidates.\n\nThis sounds like a great idea.  I do have myself to do conditional\ncherry-picks from bisect scripts, to deal with this problem.\n\n>If some bug was fixed by a merge only, the more general notation\n>\"f_1 ^b_1 ^b_1' ...\" could apply.\n\nSome more precise example may make this case more clear.\n\n\n+Fixing up known bugs\n+~~~~~~~~~~~~~~~~~~~~\n+\n+If many revisions are broken due to some unrelated but known issue that\n+is easily fixed, you might want to prefer fixing it up temporarily.\n\nIt seems natural for \"bisect run\" to use this mechanism.  What about\nthe non-automated process ?  We may want to get the fixes applied, or\nto only list available fixes to the user so he can \"git merge\" them\nmanually, or maybe an interactive selection mode ?  Probably something\nto be chosen via some config variable and flags, in a separate patch\nof the would-be series.  But what happens initially will be a good thing\nto document.\n\n+If `<commit1>` introduces a bug fixed by `<commit2>`, instruct bisect\n+to merge the latter before testing a commit that contains the former:\n+\n+------------\n+$ git bisect fix <commit1>..<commit2>\n+------------\n\nUsually, a bug also gets fixed by an official commit which does not\nfulfill the constraint of being branched at the faulty one.  In this\ncase you don't want to merge the fix if such a fix is already included,\nand thus you will need a way to specify \"alternate fixes\" to control\nthis.\n\n+A single `<commit>` acts as if `<commit>^..<commit>` was specified.\n+Fix statements can be repeated for every known bug, and are valid until\n+the bisection state is cleaned up with reset.\n\nThat is on the safe side, but we may at some point want some sort of\n\"repository of fixes\", where this info gets stored for easy reuse on\nsubsequent bisections.\n\n+Any bisect action that causes a new commit to be chosen will try to merge\n+the needed fixes and fail if they do not merge cleanly.\n\nmaybe \"... similar to what happens when a bisect-run script terminates with exit code\ngreated than 127.\" ?\n\n-- \nYann Dirson - Bertin Technologies\n"},{"id":"163409","messageId":"57605e2f4533a3c656d24f3a7ec6264e0bd949fe.1300224056.git.git@drmicha.warpmail.net","threadId":"26725","inReplyTo":"7vy64hehbh.fsf@alter.siamese.dyndns.org","subject":"[PATCHv2 1/2] git-bisect.txt: streamline run presentation","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-15T21:24:55Z","receivedAt":"2011-03-15T21:24:55Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Streamline the presentation of \"bisect run\" by removing one example\nwhich does not introduce new concepts.\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n Documentation/git-bisect.txt |   34 ++++++++--------------------------\n 1 files changed, 8 insertions(+), 26 deletions(-)\n\ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex c39d957..47e8b1e 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -274,53 +274,35 @@ $ git bisect start HEAD origin --    # HEAD is bad, origin is good\n $ git bisect run make test           # \"make test\" builds and tests\n ------------\n \n-* Automatically bisect a broken test suite:\n-+\n-------------\n-$ cat ~/test.sh\n-#!/bin/sh\n-make || exit 125                   # this skips broken builds\n-make test                          # \"make test\" runs the test suite\n-$ git bisect start v1.3 v1.1 --    # v1.3 is bad, v1.1 is good\n-$ git bisect run ~/test.sh\n-------------\n-+\n-Here we use a \"test.sh\" custom script. In this script, if \"make\"\n-fails, we skip the current commit.\n-+\n-It is safer to use a custom script outside the repository to prevent\n-interactions between the bisect, make and test processes and the\n-script.\n-+\n-\"make test\" should \"exit 0\", if the test suite passes, and\n-\"exit 1\" otherwise.\n-\n * Automatically bisect a broken test case:\n +\n ------------\n $ cat ~/test.sh\n #!/bin/sh\n make || exit 125                     # this skips broken builds\n-~/check_test_case.sh                 # does the test case passes ?\n+~/check_test_case.sh                 # does the test case pass?\n $ git bisect start HEAD HEAD~10 --   # culprit is among the last 10\n $ git bisect run ~/test.sh\n ------------\n +\n-Here \"check_test_case.sh\" should \"exit 0\" if the test case passes,\n+Here we use a \"test.sh\" custom script. In this script, if \"make\"\n+fails, we skip the current commit.\n+\"check_test_case.sh\" should \"exit 0\" if the test case passes,\n and \"exit 1\" otherwise.\n +\n-It is safer if both \"test.sh\" and \"check_test_case.sh\" scripts are\n+It is safer if both \"test.sh\" and \"check_test_case.sh\" are\n outside the repository to prevent interactions between the bisect,\n make and test processes and the scripts.\n \n-* Automatically bisect a broken test suite:\n+* Automatically bisect a broken test case:\n +\n ------------\n $ git bisect start HEAD HEAD~10 --   # culprit is among the last 10\n $ git bisect run sh -c \"make || exit 125; ~/check_test_case.sh\"\n ------------\n +\n-Does the same as the previous example, but on a single line.\n+This shows that you can do without a run script if you write the test\n+on a single line.\n \n Author\n ------\n-- \n1.7.4.1.404.g62d316\n"},{"id":"163410","messageId":"500d8098e1993b3aab3e1ff4f616ae9093cd2a1b.1300224056.git.git@drmicha.warpmail.net","threadId":"26725","inReplyTo":"7vy64hehbh.fsf@alter.siamese.dyndns.org","subject":"[PATCHv2 2/2] git-bisect.txt: example for bisecting with hot-fix","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-15T21:24:56Z","receivedAt":"2011-03-15T21:24:56Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Give an example on how to bisect when older revisions need a hot-fix to\nbuild, run or test. Triggered by the binutils/kernel issue at\n\nhttp://thread.gmane.org/gmane.comp.gnu.binutils/52601/focus=1112779\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\nThe example script is basically Junio's, with merge rather than cherry-pick.\n\n Documentation/git-bisect.txt |   33 +++++++++++++++++++++++++++++++++\n 1 files changed, 33 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex 47e8b1e..989e223 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -294,6 +294,39 @@ It is safer if both \"test.sh\" and \"check_test_case.sh\" are\n outside the repository to prevent interactions between the bisect,\n make and test processes and the scripts.\n \n+* Automatically bisect with temporary modifications (hot-fix):\n++\n+------------\n+$ cat ~/test.sh\n+#!/bin/sh\n+\n+# tweak the working tree by merging the hot-fix branch\n+# and then attempt a build\n+if\tgit merge --no-commit hot-fix &&\n+\tmake\n+then\n+\t# run project specific test and report its status\n+\t~/check_test_case.sh\n+\tstatus=$?\n+else\n+\t# tell the caller this is untestable\n+\tstatus=125\n+fi\n+\n+# undo the tweak to allow clean flipping to the next commit\n+git reset --hard\n+\n+# return control\n+exit $status\n+------------\n++\n+This applies modifications from a hot-fix branch before each test run,\n+e.g. in case your build or test environment changed so that older\n+revisions may need a fix which newer ones have already. (Make sure the\n+hot-fix branch is based off a commit which is contained in all revisions\n+which you are bisecting, so that the merge does not pull in too much, or\n+use `git cherry-pick` instead of `git merge`.)\n+\n * Automatically bisect a broken test case:\n +\n ------------\n-- \n1.7.4.1.404.g62d316\n"},{"id":"163447","messageId":"AANLkTimAaL-C_oH9X3QFUc+JOaSi7xVe93KYJuL0VEyR@mail.gmail.com","threadId":"26725","inReplyTo":"20110314210001.GE4586@gmx.de","subject":"Re: [PATCH] Document 'git bisect fix'.","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2011-03-16T09:52:21Z","receivedAt":"2011-03-16T09:52:21Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Mon, Mar 14, 2011 at 10:00 PM, Ralf Wildenhues\n<Ralf.Wildenhues@gmx.de> wrote:\n> git bisect is sometimes less effective than it could be in projects\n> with long-lived but simple bugs (e.g., little-tested configurations).\n> Rather than skipping vast revision ranges, it might be easier to fix\n> them up from known bugfix branches.\n\nIt's already possible to deal with this problem by creating a new\nbranch where the bug is fixed, and then using \"git replace\", so that\nthe new branch is used instead of the old one.\nPlease search for \"git replace\" in this doc:\n\nhttp://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html\n\n> 'git bisect fix' teaches bisect about when some known bug was\n> introduced and when it was fixed, so that bisect can merge in\n> the fix when needed into new test candidates.\n\nPerhaps some people would find it easier to use what you suggest but\nusing git replace may be nicer because you have to create the new\nbranch once, so you need to fix merge or rebase problems only once.\nAnd the new branch may be useful not only for bisecting, for example\nto recreate old versions.\n\nThanks,\nChristian.\n"},{"id":"163467","messageId":"4D80A33B.8020006@drmicha.warpmail.net","threadId":"26725","inReplyTo":"AANLkTimAaL-C_oH9X3QFUc+JOaSi7xVe93KYJuL0VEyR@mail.gmail.com","subject":"Re: [PATCH] Document 'git bisect fix'.","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-16T11:47:07Z","receivedAt":"2011-03-16T11:47:07Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Christian Couder venit, vidit, dixit 16.03.2011 10:52:\n> Hi,\n> \n> On Mon, Mar 14, 2011 at 10:00 PM, Ralf Wildenhues\n> <Ralf.Wildenhues@gmx.de> wrote:\n>> git bisect is sometimes less effective than it could be in projects\n>> with long-lived but simple bugs (e.g., little-tested configurations).\n>> Rather than skipping vast revision ranges, it might be easier to fix\n>> them up from known bugfix branches.\n> \n> It's already possible to deal with this problem by creating a new\n> branch where the bug is fixed, and then using \"git replace\", so that\n> the new branch is used instead of the old one.\n> Please search for \"git replace\" in this doc:\n> \n> http://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html\n> \n>> 'git bisect fix' teaches bisect about when some known bug was\n>> introduced and when it was fixed, so that bisect can merge in\n>> the fix when needed into new test candidates.\n> \n> Perhaps some people would find it easier to use what you suggest but\n> using git replace may be nicer because you have to create the new\n> branch once, so you need to fix merge or rebase problems only once.\n> And the new branch may be useful not only for bisecting, for example\n> to recreate old versions.\n\nI'd say the replace method is perfect for transporting an existing fix\n\"back in time\" when the range of non-bisectable commits is limited. But\nsince you have to replace the right (most recent) commit in that range\nit is less convenient when you have a fix due to a changed/exotic build\nenvironment or such which you do not want in your mainline.\n\nAlso, you have to rebase the whole history back to the commit which\nintroduced the problem - and that could be the root commit if the bisect\nproblems arise from a changed toolchain, like here.\n\nMichael\nP.S.: Did you cull cc on purpose or did gmane mess up? Readding AM, LT, TG\n"},{"id":"163506","messageId":"7vmxku7qiy.fsf@alter.siamese.dyndns.org","threadId":"26725","inReplyTo":"4D80A33B.8020006@drmicha.warpmail.net","subject":"Re: [PATCH] Document 'git bisect fix'.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-16T20:35:01Z","receivedAt":"2011-03-16T20:35:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> Christian Couder venit, vidit, dixit 16.03.2011 10:52:\n> ...\n>> It's already possible to deal with this problem by creating a new\n>> branch where the bug is fixed,...\n>\n> I'd say the replace method is perfect for transporting an existing fix\n> \"back in time\" when the range of non-bisectable commits is limited. But\n> since you have to replace the right (most recent) commit in that range\n> it is less convenient when you have a fix due to a changed/exotic build\n> environment or such which you do not want in your mainline.\n\nI totally agree with Michael.  If somebody has _already_ used \"replace\" to\nmake an alternate history in which nobody made any mistake by masking each\nand every bug fixed in the past, your bisect would be easier, but that is\nnothing more than a theoretical daydreaming. Who in the right mind would\ndo that?\n\nIf you need fixes applied for unrelated bug to even trigger the bug you\nare chasing, \"replace\" is not a practical option. You might even be the\nfirst to notice that these \"known fixes\" mattered in the part of the\nhistory you happen to be bisecting, and nobody sane would have prepared\nsuch \"replace\" in the past just in case.\n\nTreat \"replace\" as nothing more than a reimplementation of \"grafts\" done\nright (i.e. can be transferred using the usual git transfer protocols); I\ndon't want to see its use advocated for applications it is not suited.  It\njust confuses people.\n"}]}