Re: [PATCH v10.1 7/7] bisect: allow any terms set by user

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Jun 28, 2015, 06:46 UTC
Message-ID: <558F9854.5080605@alum.mit.edu>
In-Reply-To: <CAPc5daWmhkqDL0pNYne4-kRoxWK7ObcOKxtE5DsfHA2cnMM1pQ@mail.gmail.com>

On 06/28/2015 08:15 AM, Junio C Hamano wrote:

Show 11 quoted lines

> On Sat, Jun 27, 2015 at 10:51 PM, Michael Haggerty <mhagger@alum.mit.edu> 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@alum.mit.edu