Andreas Ericsson <ae@xxxxxx> writes: > I've said it before, and I'll say it again. This tool provides less > flexibility and much less power than "git checkout -b branch > <commit-ish>" (although it would be nice to have '-o' for 'overwrite > existing branch' as an argument to git checkout) True, but assembly provides more flexibility than higher level languages and you need to strike a balance between power and usability. The real question is if the structure the tool enforces to your workflow is simply being a straight-jacket or helping an average user to avoid common mistakes. One occasion I've felt the need for "seek" like feature was when starting to bisect. You usually notice breakage, so you can start with "git bisect bad HEAD", but then what next? You usually are not absolutely sure which one _was_ working the last time. If I had a seek, then I could go back to some randomly chosen version to try it out, going back until I find a good one. Maybe "git bisect try $committish" would be a good addition. We could live without it (we can just say "git reset --hard $committish"), but it can be a bit more than just that. If given committish is known to be good or bad, we could remind the user what she said the last time, and offer a chance to take it back. That is, (1) if the given $committish is an ancestor of existing good one, list those good ones and ask "do you mean you are not sure if they are good anymore, and retry the bisection?" If yes, delete those good-* refs; (2) if the given $committish is a descendant of a bad one, show it and ask "do you mean you are not sure if they are good anymore, and retry the bisection?" If yes, remove the existing bad ref. In any case, "reset --hard" to it after user responds. Other than that, I haven't felt a need for seek-like feature; instead, I make liberal use of throw-away branches. - : 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