Re: feature request - telling git bisect to skip, from inside a commit
- From
- Jim Cromie <jim.cromie@gmail.com>
- Date
- Mar 29, 2011, 17:00 UTC
- Message-ID
- <AANLkTin+0yScj2ejVgPSMmY6Q+Qk0MM+W+EqqLGphCrz@mail.gmail.com>
- In-Reply-To
- <7vipv31943.fsf@alter.siamese.dyndns.org>
On Mon, Mar 28, 2011 at 10:51 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
> 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.
Show 5 quoted lines
> > 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
Show 7 quoted lines
> > 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