On Sun, Jun 28, 2015 at 8:46 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > 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. This looks fragile to me. Unfortunately many users will probably not read it and continue, and then spend a lot of time later trying to understand what went wrong, not remembering about the message at all. The message looks like an informative message. At least we should add something like "Please check that it is what you want to do and abort with 'git bisect reset' if it is not." > For example, a session could be started with > > git bisect start --mark=broken <committish> --mark=fixed <committish> This look nearly the same as: git bisect start --name-old=broken --broken=<committish> --name-new=fixed --fixed=<committish> except that it looks safer and more backward compatible to me with --name-old and --name-new. By the way we could use "mark" or "term" instead of "name" in the option name (like --mark-old or --term-old) and in the code too if it looks clearer. > 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>] We could do that too with: git bisect start git bisect --name-old=broken broken [<committish>] git bisect --name-new=fixed fixed [<committish>] and/or: git bisect start git bisect --name-old=broken --broken=[<committish>] git bisect --name-new=fixed --fixed=[<committish>] -- 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