{"thread":{"id":"21215","subject":"[PATCH] bisect reset: Allow resetting to any commit, not just a branch","startedAt":"2009-10-12T16:38:49Z","lastAt":"2009-10-14T09:13:45Z","messageCount":18,"participants":["Anders Kaseorg","Junio C Hamano","Johannes Sixt","Christian Couder"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"124714","messageId":"alpine.DEB.1.10.0910121237540.2223@dr-wily.mit.edu","threadId":"21215","inReplyTo":null,"subject":"[PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Anders Kaseorg","fromEmail":"andersk@mit.edu","sentAt":"2009-10-12T16:38:49Z","receivedAt":"2009-10-12T16:38:49Z","isPatch":true,"sender":{"key":"andersk@mit.edu","avatar":"https://avatars.githubusercontent.com/u/26471?v=4"},"body":"‘git bisect reset’ could already checkout an arbitrary commit if you\nwere on a detached HEAD before starting the bisection. This lets you\nspecify an arbitrary commit to ‘git bisect reset ’.\n\nThis also provides a way to clean the bisection state without moving\nHEAD: ‘git bisect reset HEAD’.\n\nSigned-off-by: Anders Kaseorg \n---\n git-bisect.sh | 3 +--\n 1 files changed, 1 insertions(+), 2 deletions(-)\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 6f6f039..d319b9f 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -311,8 +311,7 @@ bisect_reset() {\n \t}\n \tcase \"$#\" in\n \t0) branch=$(cat \"$GIT_DIR/BISECT_START\") ;;\n-\t1) git show-ref --verify --quiet -- \"refs/heads/$1\" ||\n-\t die \"$1 does not seem to be a valid branch\"\n+\t1) git rev-parse --verify \"$1^{commit}\" || exit\n \t branch=\"$1\" ;;\n \t*)\n \t usage ;;\n-- \n1.6.5\n"},{"id":"124758","messageId":"7vr5t8coex.fsf@alter.siamese.dyndns.org","threadId":"21215","inReplyTo":"alpine.DEB.1.10.0910121237540.2223@dr-wily.mit.edu","subject":"Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-12T21:06:46Z","receivedAt":"2009-10-12T21:06:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Anders Kaseorg writes:\n\n> ‘git bisect reset’ could already checkout an arbitrary commit if you\n> were on a detached HEAD before starting the bisection. This lets you\n> specify an arbitrary commit to ‘git bisect reset ’.\n>\n> This also provides a way to clean the bisection state without moving\n> HEAD: ‘git bisect reset HEAD’.\n>\n> Signed-off-by: Anders Kaseorg \n> ---\n> git-bisect.sh | 3 +--\n> 1 files changed, 1 insertions(+), 2 deletions(-)\n>\n> diff --git a/git-bisect.sh b/git-bisect.sh\n> index 6f6f039..d319b9f 100755\n> --- a/git-bisect.sh\n> +++ b/git-bisect.sh\n> @@ -311,8 +311,7 @@ bisect_reset() {\n> \t}\n> \tcase \"$#\" in\n> \t0) branch=$(cat \"$GIT_DIR/BISECT_START\") ;;\n> -\t1) git show-ref --verify --quiet -- \"refs/heads/$1\" ||\n> -\t die \"$1 does not seem to be a valid branch\"\n> +\t1) git rev-parse --verify \"$1^{commit}\" || exit\n> \t branch=\"$1\" ;;\n> \t*)\n> \t usage ;;\n\nThanks.\n\nThe \"one parameter\" case dates back to the original bisect implementation\nin commit 8cc6a08 (Making it easier to find which change introduced a bug,\n2005-07-30), and the only reason of existence for that case was that the\ncode looked like this back then:\n\n bisect_reset() {\n case \"$#\" in\n 0) branch=master ;;\n 1) test -f \"$GIT_DIR/refs/heads/$1\" || {\n echo >&2 \"$1 does not seem to be a valid branch\"\n exit 1\n }\n branch=\"$1\" ;;\n *)\n usage ;;\n esac\n ...\n\nAn important difference to notice, compared to a more recent version, is\nthat we did not remember (nor use) the original branch, and without an\nargument we always switched to 'master'. Back then, the user who started\nbisecting a side branch needed to remember the name of the branch before\nstarting the bisection, and needed to give that to the reset subcommand.\n\nBecause we remember where we came from these days, I do not think it makes\nmuch sense to even keep this \"one parameter\" case, let alone extending\nthis interface to allow switching to an arbitrary commit.\n\nI even think that the support for an explicit branch name in the reset\nsubcommand should eventually be deprecated, perhaps unless it matches what\nis stored in BISECT_START.\n\nThe documentation, does not even talk about what the optional \nargument is good for, even though it lists the optional in the\nsynopsis section.\n\nHaving said all that, four years and two months are looooooong time in git\ntimescale, and I am discounting, without any evidence to judge either way,\nthe possibility that people may have learned during that time to (ab)use\nthis as a (very useful?) shortcut to finish the current bisection and\nswitch to some entirely different branch.\n\nI offhand do not see a good rationale for such a shortcut to finish bisect\nand switch to another branch (IOW, I understand \"it is shorter to type\",\nbut I do not see \"it is often done and very useful\"), but I am open to be\nenlightened by a workflow where such a shortcut is useful.\n"},{"id":"124761","messageId":"alpine.DEB.2.00.0910121708030.5105@dr-wily.mit.edu","threadId":"21215","inReplyTo":"7vr5t8coex.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Anders Kaseorg","fromEmail":"andersk@mit.edu","sentAt":"2009-10-12T21:31:03Z","receivedAt":"2009-10-12T21:31:03Z","isPatch":true,"sender":{"key":"andersk@mit.edu","avatar":"https://avatars.githubusercontent.com/u/26471?v=4"},"body":"On Mon, 12 Oct 2009, Junio C Hamano wrote:\n> I offhand do not see a good rationale for such a shortcut to finish \n> bisect and switch to another branch (IOW, I understand \"it is shorter to \n> type\", but I do not see \"it is often done and very useful\"), but I am \n> open to be enlightened by a workflow where such a shortcut is useful.\n\nI agree that ‘git bisect reset ’ is a confusing shortcut. It only \nreally made sense before Git supported detached HEADs, and you needed to \nbe on a branch all the time. I think that lifting the arbitrary \nrestriction to branch names makes it less confusing, but if you want to \nremove the argument altogether, that would eliminate the confusion \nentirely.\n\nI had in mind only one case where ‘git bisect reset ’ would be \nuseful. I often don’t even remember what commit I was on before I started \na bisect, much less believe that I want to immediately switch back to it. \nI would prefer to be able to clean the bisection state without checking \nout another commit at all, because that takes forever and invalidates my \ncompiled tree. This is what ‘git bisect reset HEAD’ would do if it \nworked.\n\nPerhaps it makes sense to add a command that just clears the bisection \nstate. ‘git bisect stop’?\n\nAnders\n"},{"id":"124777","messageId":"7vaazw6uyi.fsf@alter.siamese.dyndns.org","threadId":"21215","inReplyTo":"alpine.DEB.2.00.0910121708030.5105@dr-wily.mit.edu","subject":"Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-12T23:41:57Z","receivedAt":"2009-10-12T23:41:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Anders Kaseorg writes:\n\n> I had in mind only one case where ‘git bisect reset ’ would be \n> useful. I often don’t even remember what commit I was on before I started \n> a bisect, much less believe that I want to immediately switch back to it. \n> I would prefer to be able to clean the bisection state without checking \n> out another commit at all, because that takes forever and invalidates my \n> compiled tree. This is what ‘git bisect reset HEAD’ would do if it \n> worked.\n\nI am not sure what \"removing bisect states\" really buys you.\n\nIf having bisect states somehow interferes what you need to do in order to\ndecide which commit you want to switch to, it may make sense to do 'git\nbisect reset HEAD' or 'git bisect stop', before starting whatever you need\nto do to make that decision.\n\nBut I do not know how it hurts to still have bisect states around, in\norder to find where you want to go next. Could you elaborate?\n\nBut your explanation \"I often don't even remember\" makes sense to me.\n\nI would understand it, if not agreeing that I also am often in that\nsituation myself\", if somebody does not even care which commit he was on\nbefore starting the bisection, but knows (or is willing to decide at that\npoint) which branch (or even a specific commit, while still being\ndetached) he wants to switch to. And it would make sense to avoid an\nextra checkout that snaps back to the pre-bisection commit before\nswitching to the new state he has chosen.\n\nSo in that sense, I would agree with your original patch more than I would\nagree with what you suggested as an alternative (i.e. \"git bisect stop\"\nwhich is what \"git bisect reset HEAD\" would do if we do not verify the\nargument is the name of an existing branch) in your response.\n\nI am inclined to ask you to come up with a paragraph in the documentation\nto discuss how the optional (now it will be ) parameter\nto the reset subcommand is meant to be used and re-submit the original\npatch, perhaps with an updated commit log message. \"Allow resetting to\nany\" said only what the patch does, without saying why such a mode of\noperation was even a good thing to begin with.\n\nThanks.\n"},{"id":"124813","messageId":"4AD420BC.5060506@viscovery.net","threadId":"21215","inReplyTo":"7vr5t8coex.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-10-13T06:39:56Z","receivedAt":"2009-10-13T06:39:56Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> I even think that the support for an explicit branch name in the reset\n> subcommand should eventually be deprecated, perhaps unless it matches what\n> is stored in BISECT_START.\n\nGoodness, NO!\n\n> The documentation, does not even talk about what the optional \n> argument is good for, even though it lists the optional in the\n> synopsis section.\n\nIf I had know about this feature (yes, FEATURE), I would have used it like\nthis in the past:\n\n $ git branch tmp\n $ git bisect reset tmp\n $ git branch -d tmp\n\nWith the patch proposed by Anders this shortens to:\n\n $ git bisect reset HEAD\n\n> Having said all that, four years and two months are looooooong time in git\n> timescale, and I am discounting, without any evidence to judge either way,\n> the possibility that people may have learned during that time to (ab)use\n> this as a (very useful?) shortcut to finish the current bisection and\n> switch to some entirely different branch.\n\nIn all the bisect runs that I have done in my live, the ONLY way I wanted\n'bisect reset' to act was to NOT change the commit it currently was on.\nThe fact that it switched back to the commit or branch that the bisect was\nstarted on, was always a major inconvenience.\n\nSo, I have no problem if you want to deprecate the branch parameter, if at\nthe same time bisect reset no longer switches to some other commit. ;)\n\n> I offhand do not see a good rationale for such a shortcut to finish bisect\n> and switch to another branch (IOW, I understand \"it is shorter to type\",\n> but I do not see \"it is often done and very useful\"), but I am open to be\n> enlightened by a workflow where such a shortcut is useful.\n\nIn my workflow, after I've found the bad commit, I always want bisect to\nstay at the commit that it found. I don't want it to warp me somewhere\nelse; I want to make the decision where to go next myself.\n\n-- Hannes\n"},{"id":"124814","messageId":"4AD42203.6030802@viscovery.net","threadId":"21215","inReplyTo":"7vaazw6uyi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-10-13T06:45:23Z","receivedAt":"2009-10-13T06:45:23Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> I would understand it, if not agreeing that I also am often in that\n> situation myself\", if somebody does not even care which commit he was on\n> before starting the bisection, but knows (or is willing to decide at that\n> point) which branch (or even a specific commit, while still being\n> detached) he wants to switch to. And it would make sense to avoid an\n> extra checkout that snaps back to the pre-bisection commit before\n> switching to the new state he has chosen.\n\nThe situation that I'm faced quite frequently is that after I find a\nregression, I cannot tell which released version did not have the\nbreakage. Hence, the first thing I have to do is to find a good commit.\nTherefore, I jump around in ancient history until I find a good commit.\nThen I start bisect. I certainly do NOT want to be warped back to this\nancient commit by 'bisect reset'.\n\n-- Hannes\n"},{"id":"124816","messageId":"7v3a5n3hgn.fsf@alter.siamese.dyndns.org","threadId":"21215","inReplyTo":"4AD420BC.5060506@viscovery.net","subject":"Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-13T07:01:44Z","receivedAt":"2009-10-13T07:01:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> In my workflow, after I've found the bad commit, I always want bisect to\n> stay at the commit that it found. I don't want it to warp me somewhere\n> else; I want to make the decision where to go next myself.\n\nAre you sure about what you are saying?\n\nHalf of the time, the commit you test in your \"git bisect\" section would\nbe a \"good\" one, and immediately after you tell it \"bisect good\", it tells\nyou that some _other_ commit you marked \"bad\" is the first bad commit. In\nsuch a case, you won't be on the commit that the bisect has found.\n\nSo I _do_ agree that you would always want to stare at the commit that is\nthe first bad one, leaving the bisection session at the detached HEAD\nstate bisection session ends at is _totally_ different from what you want.\n"},{"id":"124817","messageId":"alpine.DEB.2.00.0910130250270.5105@dr-wily.mit.edu","threadId":"21215","inReplyTo":"7vaazw6uyi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Anders Kaseorg","fromEmail":"andersk@mit.edu","sentAt":"2009-10-13T07:03:31Z","receivedAt":"2009-10-13T07:03:31Z","isPatch":true,"sender":{"key":"andersk@mit.edu","avatar":"https://avatars.githubusercontent.com/u/26471?v=4"},"body":"On Mon, 12 Oct 2009, Junio C Hamano wrote:\n> But I do not know how it hurts to still have bisect states around, in\n> order to find where you want to go next. Could you elaborate?\n\nMostly little irritations. Extra bisect/* refs show up in gitk. If you \nuse __git_ps1 in your prompt (from git-completion.bash), it adds \n|BISECTING to your prompt.\n\nAlso, I just noticed that if you start a new bisection without ever \ncleaning up the old one, the next ‘git bisect reset’ will bring you back \nto HEAD before the old bisection instead of HEAD before the new one, which \nis not what you would expect if you forgot that the old bisection ever \nhappened.\n\n> I am inclined to ask you to come up with a paragraph in the \n> documentation to discuss how the optional (now it will be \n> ) parameter to the reset subcommand is meant to be used and \n> re-submit the original patch, perhaps with an updated commit log \n> message.\n\nI note that the ‘git checkout’ documentation mentions and not \n, perhaps to emphasize that HEAD will become attached to the \nbranch if you specify a branch name. Do you think it makes sense for \nthese to be documented differently?\n\nAnders\n"},{"id":"124825","messageId":"7vbpkb21yp.fsf@alter.siamese.dyndns.org","threadId":"21215","inReplyTo":"4AD42203.6030802@viscovery.net","subject":"Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-13T07:21:50Z","receivedAt":"2009-10-13T07:21:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> The situation that I'm faced quite frequently is that after I find a\n> regression, I cannot tell which released version did not have the\n> breakage. Hence, the first thing I have to do is to find a good commit.\n> Therefore, I jump around in ancient history until I find a good commit.\n> Then I start bisect. I certainly do NOT want to be warped back to this\n> ancient commit by 'bisect reset'.\n\nUnlike your other message, now, I can see _this_ one making sense very\nmuch.\n\nIt is a very good explanation as to why BISECT_START (whose sole purpose\nis to go back there) is not a very useful concept. What you wrote deserve\nto go to the \"bisect reset\" documentation to explain what the optional\n argument (perhaps we would make it a with Anders's\npatch) is good for and how it is intended to be used.\n"},{"id":"124826","messageId":"4AD43002.5080003@viscovery.net","threadId":"21215","inReplyTo":"7v3a5n3hgn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-10-13T07:45:06Z","receivedAt":"2009-10-13T07:45:06Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> Half of the time, the commit you test in your \"git bisect\" section would\n> be a \"good\" one, and immediately after you tell it \"bisect good\", it tells\n> you that some _other_ commit you marked \"bad\" is the first bad commit. In\n> such a case, you won't be on the commit that the bisect has found.\n\nOh, yes, very true; but it is very close. But the commit that git bisect\nreset warps me to is perhaps 1000 steps in history away. I certainly do\nnot want to go there, ever, because I want to go back near the bad commit\nright away. (Think of fewer files changed means less build time.) If git\nbisect reset would check out the bad commit, this would be *very* convenient.\n\n-- Hannes\n"},{"id":"124828","messageId":"7vtyy3zo9m.fsf@alter.siamese.dyndns.org","threadId":"21215","inReplyTo":"4AD43002.5080003@viscovery.net","subject":"Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-13T08:33:41Z","receivedAt":"2009-10-13T08:33:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Junio C Hamano schrieb:\n>> Half of the time, the commit you test in your \"git bisect\" section would\n>> be a \"good\" one, and immediately after you tell it \"bisect good\", it tells\n>> you that some _other_ commit you marked \"bad\" is the first bad commit. In\n>> such a case, you won't be on the commit that the bisect has found.\n>\n> Oh, yes, very true; but it is very close. But the commit that git bisect\n> reset warps me to is perhaps 1000 steps in history away. I certainly do\n> not want to go there, ever, because I want to go back near the bad commit\n> right away. (Think of fewer files changed means less build time.) If git\n> bisect reset would check out the bad commit, this would be *very* convenient.\n\nI agree that \"git bisect reset-and-detach-at-the-first-bad-one\" would make\na lot of sense.\n\nIn my workflow, after I chased a bug in frotz, I often do\n\n $ git name-rev $the_bad_one_that_was_found\n \nto learn what was the first tagged release that has the bug, and create a\ntopic from there:\n\n $ git checkout -b jc/maint-X.Y.Z-fix-frotz $the_bad_one_that_was_found\n\nso that the fix I'd build on the commit can be merged initially to 'pu',\nthen 'next', then 'maint-X.Y.Z' and upwards to 'master', but all of that\nis done after \"git bisect reset\" to switch back to the 'master' branch.\nIt is cumbersome to have to type (actually, I use the cut buffer in screen)\nthe commit object name of the first bad one twice.\n\nIt certainly sounds attractive if we can do:\n\n $ git bisect reset-and-detach-at-the-first-bad-one\n $ git name-rev HEAD\n $ git checkout -b jc/maint-X.Y.Z-fix-frotz\n $ hack hack hack\n $ git commit\n\nBut at that point we are not talking about switching to arbitrary commit\nanymore.\n"},{"id":"124847","messageId":"alpine.DEB.2.00.0910131025220.5105@dr-wily.mit.edu","threadId":"21215","inReplyTo":"7vtyy3zo9m.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Anders Kaseorg","fromEmail":"andersk@mit.edu","sentAt":"2009-10-13T14:29:20Z","receivedAt":"2009-10-13T14:29:20Z","isPatch":true,"sender":{"key":"andersk@mit.edu","avatar":"https://avatars.githubusercontent.com/u/26471?v=4"},"body":"On Tue, 13 Oct 2009, Junio C Hamano wrote:\n> I agree that \"git bisect reset-and-detach-at-the-first-bad-one\" would make\n> a lot of sense.\n\nUnder my patch, that’s ‘git bisect reset bisect/bad’. Similar arguments \nmay be made as to whether that should or shouldn’t be a separate command \n(although it’s less clear what to call it, in this case).\n\nAnders\n"},{"id":"124849","messageId":"alpine.DEB.2.00.0910131116300.5105@dr-wily.mit.edu","threadId":"21215","inReplyTo":"7vaazw6uyi.fsf@alter.siamese.dyndns.org","subject":"[PATCH v2] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Anders Kaseorg","fromEmail":"andersk@mit.edu","sentAt":"2009-10-13T15:22:42Z","receivedAt":"2009-10-13T15:22:42Z","isPatch":true,"sender":{"key":"andersk@mit.edu","avatar":"https://avatars.githubusercontent.com/u/26471?v=4"},"body":"‘git bisect reset’ accepts an optional argument specifying a branch to\ncheck out after cleaning up the bisection state. This lets you\nspecify an arbitrary commit.\n\nIn particular, this provides a way to clean the bisection state\nwithout moving HEAD: ‘git bisect reset HEAD’. This may be useful if\nyou are not interested in the state before you began a bisect,\nespecially if checking out the old commit would be expensive and\ninvalidate most of your compiled tree.\n\nClarify the ‘git bisect reset’ documentation to explain this optional\nargument, which was previously mentioned only in the usage message.\n\nSigned-off-by: Anders Kaseorg \n---\n Documentation/git-bisect.txt | 23 +++++++++++++++++------\n git-bisect.sh | 7 +++----\n 2 files changed, 20 insertions(+), 10 deletions(-)\n\ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex 63e7a42..d2ffae0 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -20,7 +20,7 @@ on the subcommand:\n git bisect bad []\n git bisect good [...]\n git bisect skip [(|)...]\n- git bisect reset []\n+ git bisect reset []\n git bisect visualize\n git bisect replay \n git bisect log\n@@ -81,16 +81,27 @@ will have been left with the first bad kernel revision in \"refs/bisect/bad\".\n Bisect reset\n ~~~~~~~~~~~~\n \n-To return to the original head after a bisect session, issue the\n-following command:\n+After a bisect session, to clean up the bisection state and return to\n+the original HEAD, issue the following command:\n \n ------------------------------------------------\n $ git bisect reset\n ------------------------------------------------\n \n-This resets the tree to the original branch instead of being on the\n-bisection commit (\"git bisect start\" will also do that, as it resets\n-the bisection state).\n+By default, this will return your tree to the commit that was checked\n+out before `git bisect start`. (A new `git bisect start` will also do\n+that, as it cleans up the old bisection state.)\n+\n+With an optional argument, you can return to a different commit\n+instead:\n+\n+------------------------------------------------\n+$ git bisect reset \n+------------------------------------------------\n+\n+For example, `git bisect reset HEAD` will leave you on the current\n+bisection commit and avoid switching commits at all, while `git bisect\n+reset bisect/bad` will check out the first bad revision.\n \n Bisect visualize\n ~~~~~~~~~~~~~~~~\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 6f6f039..0c56c26 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -13,8 +13,8 @@ git bisect skip [(|)...]\n mark ... untestable revisions.\n git bisect next\n find next bisection to test and check it out.\n-git bisect reset []\n- finish bisection search and go back to branch.\n+git bisect reset []\n+ finish bisection search and go back to commit.\n git bisect visualize\n show bisect status in gitk.\n git bisect replay \n@@ -311,8 +311,7 @@ bisect_reset() {\n \t}\n \tcase \"$#\" in\n \t0) branch=$(cat \"$GIT_DIR/BISECT_START\") ;;\n-\t1) git show-ref --verify --quiet -- \"refs/heads/$1\" ||\n-\t die \"$1 does not seem to be a valid branch\"\n+\t1) git rev-parse --verify \"$1^{commit}\" || exit\n \t branch=\"$1\" ;;\n \t*)\n \t usage ;;\n-- \n1.6.5\n"},{"id":"124881","messageId":"200910132206.18460.chriscool@tuxfamily.org","threadId":"21215","inReplyTo":"alpine.DEB.2.00.0910131116300.5105@dr-wily.mit.edu","subject":"Re: [PATCH v2] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-10-13T20:06:18Z","receivedAt":"2009-10-13T20:06:18Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tuesday 13 October 2009, Anders Kaseorg wrote:\n> @@ -311,8 +311,7 @@ bisect_reset() {\n> \t}\n> \tcase \"$#\" in\n> \t0) branch=$(cat \"$GIT_DIR/BISECT_START\") ;;\n> -\t1) git show-ref --verify --quiet -- \"refs/heads/$1\" ||\n> -\t die \"$1 does not seem to be a valid branch\"\n> +\t1) git rev-parse --verify \"$1^{commit}\" || exit\n> \t branch=\"$1\" ;;\n> \t*)\n> \t usage ;;\n\nI agree with the purpose of the patch but I think something like the \nfollowing would be better:\n\n@@ -311,8 +311,8 @@ bisect_reset() {\n }\n case \"$#\" in\n 0) branch=$(cat \"$GIT_DIR/BISECT_START\") ;;\n- 1) git show-ref --verify --quiet -- \"refs/heads/$1\" ||\n- die \"$1 does not seem to be a valid branch\"\n+ 1) git rev-parse --quiet --verify \"$1^{commit}\" > /dev/null ||\n+ die \"'$1' does not seem to point to a valid commit\"\n branch=\"$1\" ;;\n *)\n usage ;;\n\nIt would give a better error message when \"git rev-parse\" fails instead of:\n\nfatal: Needed a single revision\n\nand it would not print the SHA1 from \"$1^{commit}\" when \"git rev-parse\" \nsucceeds.\n\nBest regards,\nChristian.\n"},{"id":"124884","messageId":"alpine.DEB.2.00.0910131605170.5105@dr-wily.mit.edu","threadId":"21215","inReplyTo":"200910132206.18460.chriscool@tuxfamily.org","subject":"Re: [PATCH v2] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Anders Kaseorg","fromEmail":"andersk@mit.edu","sentAt":"2009-10-13T20:09:31Z","receivedAt":"2009-10-13T20:09:31Z","isPatch":true,"sender":{"key":"andersk@mit.edu","avatar":"https://avatars.githubusercontent.com/u/26471?v=4"},"body":"On Tue, 13 Oct 2009, Christian Couder wrote:\n> + 1) git rev-parse --quiet --verify \"$1^{commit}\" > /dev/null ||\n> + die \"'$1' does not seem to point to a valid commit\"\n> \n> It would give a better error message when \"git rev-parse\" fails instead of:\n> \n> fatal: Needed a single revision\n> \n> and it would not print the SHA1 from \"$1^{commit}\" when \"git rev-parse\" \n> succeeds.\n\nOh, oops, I somehow lost the > /dev/null in my version.\n\nBut as for the ‘git rev-parse’ error being confusing, why don’t we fix \n‘git rev-parse’ instead?\n\nAnders\n"},{"id":"124889","messageId":"200910132230.04498.chriscool@tuxfamily.org","threadId":"21215","inReplyTo":"alpine.DEB.2.00.0910131605170.5105@dr-wily.mit.edu","subject":"Re: [PATCH v2] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-10-13T20:30:04Z","receivedAt":"2009-10-13T20:30:04Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tuesday 13 October 2009, Anders Kaseorg wrote:\n> On Tue, 13 Oct 2009, Christian Couder wrote:\n> > + 1) git rev-parse --quiet --verify \"$1^{commit}\" > /dev/null ||\n> > + die \"'$1' does not seem to point to a valid commit\"\n> >\n> > It would give a better error message when \"git rev-parse\" fails instead\n> > of:\n> >\n> > fatal: Needed a single revision\n> >\n> > and it would not print the SHA1 from \"$1^{commit}\" when \"git rev-parse\"\n> > succeeds.\n>\n> Oh, oops, I somehow lost the > /dev/null in my version.\n>\n> But as for the ‘git rev-parse’ error being confusing, why don’t we fix\n> ‘git rev-parse’ instead?\n\nIt's a plumbing command, and the output of plumbing commands is not supposed \nto change a lot as some scripts may rely on it.\n\nAnd anyway that would be in another patch.\n\nBest regards,\nChristian.\n"},{"id":"124896","messageId":"alpine.DEB.2.00.0910131700320.5105@dr-wily.mit.edu","threadId":"21215","inReplyTo":"200910132206.18460.chriscool@tuxfamily.org","subject":"[PATCH v3] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Anders Kaseorg","fromEmail":"andersk@mit.edu","sentAt":"2009-10-13T21:02:24Z","receivedAt":"2009-10-13T21:02:24Z","isPatch":true,"sender":{"key":"andersk@mit.edu","avatar":"https://avatars.githubusercontent.com/u/26471?v=4"},"body":"‘git bisect reset’ accepts an optional argument specifying a branch to\ncheck out after cleaning up the bisection state. This lets you\nspecify an arbitrary commit.\n\nIn particular, this provides a way to clean the bisection state\nwithout moving HEAD: ‘git bisect reset HEAD’. This may be useful if\nyou are not interested in the state before you began a bisect,\nespecially if checking out the old commit would be expensive and\ninvalidate most of your compiled tree.\n\nClarify the ‘git bisect reset’ documentation to explain this optional\nargument, which was previously mentioned only in the usage message.\n\nSigned-off-by: Anders Kaseorg \n---\n Documentation/git-bisect.txt | 23 +++++++++++++++++------\n git-bisect.sh | 8 ++++----\n 2 files changed, 21 insertions(+), 10 deletions(-)\n\ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex 63e7a42..d2ffae0 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -20,7 +20,7 @@ on the subcommand:\n git bisect bad []\n git bisect good [...]\n git bisect skip [(|)...]\n- git bisect reset []\n+ git bisect reset []\n git bisect visualize\n git bisect replay \n git bisect log\n@@ -81,16 +81,27 @@ will have been left with the first bad kernel revision in \"refs/bisect/bad\".\n Bisect reset\n ~~~~~~~~~~~~\n \n-To return to the original head after a bisect session, issue the\n-following command:\n+After a bisect session, to clean up the bisection state and return to\n+the original HEAD, issue the following command:\n \n ------------------------------------------------\n $ git bisect reset\n ------------------------------------------------\n \n-This resets the tree to the original branch instead of being on the\n-bisection commit (\"git bisect start\" will also do that, as it resets\n-the bisection state).\n+By default, this will return your tree to the commit that was checked\n+out before `git bisect start`. (A new `git bisect start` will also do\n+that, as it cleans up the old bisection state.)\n+\n+With an optional argument, you can return to a different commit\n+instead:\n+\n+------------------------------------------------\n+$ git bisect reset \n+------------------------------------------------\n+\n+For example, `git bisect reset HEAD` will leave you on the current\n+bisection commit and avoid switching commits at all, while `git bisect\n+reset bisect/bad` will check out the first bad revision.\n \n Bisect visualize\n ~~~~~~~~~~~~~~~~\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 6f6f039..8b3c585 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -13,8 +13,8 @@ git bisect skip [(|)...]\n mark ... untestable revisions.\n git bisect next\n find next bisection to test and check it out.\n-git bisect reset []\n- finish bisection search and go back to branch.\n+git bisect reset []\n+ finish bisection search and go back to commit.\n git bisect visualize\n show bisect status in gitk.\n git bisect replay \n@@ -311,8 +311,8 @@ bisect_reset() {\n \t}\n \tcase \"$#\" in\n \t0) branch=$(cat \"$GIT_DIR/BISECT_START\") ;;\n-\t1) git show-ref --verify --quiet -- \"refs/heads/$1\" ||\n-\t die \"$1 does not seem to be a valid branch\"\n+\t1) git rev-parse --quiet --verify \"$1^{commit}\" > /dev/null ||\n+\t die \"'$1' is not a valid commit\"\n \t branch=\"$1\" ;;\n \t*)\n \t usage ;;\n-- \n1.6.5\n"},{"id":"124954","messageId":"7v1vl6fid2.fsf@alter.siamese.dyndns.org","threadId":"21215","inReplyTo":"alpine.DEB.2.00.0910131700320.5105@dr-wily.mit.edu","subject":"Re: [PATCH v3] bisect reset: Allow resetting to any commit, not just a branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-14T09:13:45Z","receivedAt":"2009-10-14T09:13:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks; will replace your v2 that was queued in 'pu'.\n"}]}