Re: feature request - telling git bisect to skip, from inside a commit

[Jim Cromie <jim.cromie@gmail.com>]

On Mon, Mar 28, 2011 at 10:51 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> That could work, though I would spell it as a pseudo-header:
>>
>>   Bisect: Skip
>>
>> at the end of each commit.

I like this generically.  It is more constrained than a
/^bisect skip(.*)$/ matching, and perhaps easier to code.

Thank you for reading into my request and formulating a better version,
the discussion/explication of issues also helps.

If the pseudo-header can be added into the commit message,
it is trivial to use.

I see the merit of a skip-cache as working after-the-fact
on already published/shared patch-sets, but Im unsure how the
skip-cache can be shared currently.

>
> I think that is a saner approach, and further say it would be much saner
> to make that token something like
>
>    Broken: does not build

My only concern here is the negative connotation of Broken.
At least in my 1/2 change scenario, thats known to be incomplete,
its kinda pejorative.  But it certainly gets the job done.

Skip: make rc 125
Skip: 125
Skip: gcc error: no such field: foo
Skip: api change only, users must follow

Skip: has less pejorative, and closer name-association linkage
to the bisect skip command that it

>
> A commit may or may not build, a build product may work in some areas just
> fine and may have known bugs in some other areas, depending on what kind
> of breakage you are interested in.  You might even be looking for a change
> that fixed a bug for cherry picking.  In short, "Bisect: Skip" is too
> broad a brush, and does not convey enough information.
>

agreed -  It would be interesting, 6 months after the feature is added (I hope),
 to search commit messages and see how the header has been used.

> And then teach the script you give to "bisect run" to grep for that
> "^Broken: " pattern to answer with exit 125 (cannot test), and you are
> done.
>

With this, nothing needs to be added.
The only advantage to bisect looking for the pseudo-header is that
a convention is supported, such that it might get used.
I suppose a 1 line addition to git bisect run documentation would
do just as well.

thanks