On Mon, 12 Oct 2009, Junio C Hamano wrote: > 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? Mostly little irritations. Extra bisect/* refs show up in gitk. If you use __git_ps1 in your prompt (from git-completion.bash), it adds |BISECTING to your prompt. Also, I just noticed that if you start a new bisection without ever cleaning up the old one, the next ‘git bisect reset’ will bring you back to HEAD before the old bisection instead of HEAD before the new one, which is not what you would expect if you forgot that the old bisection ever happened. > 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. I note that the ‘git checkout’ documentation mentions <branch> and not <commit>, perhaps to emphasize that HEAD will become attached to the branch if you specify a branch name. Do you think it makes sense for these to be documented differently? Anders -- 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