Anders Kaseorg <andersk@xxxxxxx> writes: > I had in mind only one case where ‘git bisect reset <commit>’ would be > useful. I often don’t even remember what commit I was on before I started > a bisect, much less believe that I want to immediately switch back to it. > I would prefer to be able to clean the bisection state without checking > out another commit at all, because that takes forever and invalidates my > compiled tree. This is what ‘git bisect reset HEAD’ would do if it > worked. I am not sure what "removing bisect states" really buys you. If having bisect states somehow interferes what you need to do in order to decide which commit you want to switch to, it may make sense to do 'git bisect reset HEAD' or 'git bisect stop', before starting whatever you need to do to make that decision. But I do not know how it hurts to still have bisect states around, in order to find where you want to go next. Could you elaborate? But your explanation "I often don't even remember" makes sense to me. I would understand it, if not agreeing that I also am often in that situation myself", if somebody does not even care which commit he was on before starting the bisection, but knows (or is willing to decide at that point) which branch (or even a specific commit, while still being detached) he wants to switch to. And it would make sense to avoid an extra checkout that snaps back to the pre-bisection commit before switching to the new state he has chosen. So in that sense, I would agree with your original patch more than I would agree with what you suggested as an alternative (i.e. "git bisect stop" which is what "git bisect reset HEAD" would do if we do not verify the argument is the name of an existing branch) in your response. I am inclined to ask you to come up with a paragraph in the documentation to discuss how the optional <branch> (now it will be <commit>) parameter to the reset subcommand is meant to be used and re-submit the original patch, perhaps with an updated commit log message. "Allow resetting to any" said only what the patch does, without saying why such a mode of operation was even a good thing to begin with. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html