On Mon, Mar 28, 2011 at 10:51 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jeff King <peff@xxxxxxxx> 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 -- 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