On 06/28/2015 08:15 AM, Junio C Hamano wrote: > On Sat, Jun 27, 2015 at 10:51 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: >> >> I would like to remind everybody of my old claim that it would be >> possible to teach `git bisect` to infer by itself which term means >> "older" and which term means "newer": >> >> http://article.gmane.org/gmane.comp.version-control.git/244036 > > But then one mistake at the beginning and the user will be on a wrong > track during the whole bisect session, no? Unless you make absolutely > clear when making the "intelligent" decision what Git inferred, that is. Definitely, `git bisect` should tell the user what it inferred. > For something complex like bisect, I highly suspect that a tool that is > more intelligent than the end users (more precisely, a tool that it thinks > it is more intelligent) would hurt them more than it helps them. This isn't about making bisect "more intelligent than the end users". It is about not forcing the user cumbersomely to spell out redundant information because the tool is too stupid. If I mark one commit "broken" and another commit "fixed", and the "broken" commit is an ancestor of the "fixed" commit, then it is pretty obvious that I am looking for the commit that caused the transition "broken" -> "fixed". The same if I mark one commit "xyzzy" and the other one "plugh". I understand that the user might make a mistake when marking the initial commits, but as soon as bisect says Commit <sha1-abbrev> is an ancestor of <sha1-abbrev>, so I will look for the commit that caused the transition from "xyzzy" to "plugh". then I hope the user will notice and correct her/his mistake. For example, a session could be started with git bisect start --mark=broken <committish> --mark=fixed <committish> and from then on git bisect broken git bisect fixed Or, if the user doesn't want to specify both endpoints on the `start` line, git bisect start git bisect --mark=broken [<committish>] git bisect --mark=fixed [<committish>] Essentially, specifying `--mark=<name>` once would make `<name>` a shorthand for `--mark=<name>`. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx -- 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