Christian Couder <christian.couder@xxxxxxxxx> writes: > On Sun, Jun 28, 2015 at 8:46 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: >> 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, I don't understand what you mean by "went wrong". As a user, when I discovered "git bisect", I was actually surprised that it expected one particular order between good and bad. I would have expected to be able to say "this is good, this is bad, tell me where it changed" without having an idea of who's good and who's bad. In particular when bisecting from two branches, the user knows that branch A is good, and branch B is bad, but does not necessarily know whether it's a regression in B or a fix in A. The fact that bisect can find out should be just "normal" from the user point of view. There's no mistake involved, nothing to fix, and nothing that went wrong. > 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. I prefer "term" to "mark" because "mark" is both a verb and a noun, so --mark-old=foo could mean both "mark foo as old" or "the name of the marks for old commits is foo". I think I prefer "term" to "name". -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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