git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 7/7] bisect: use "rev-list --bisect-skip" and remove "filter_skipped" function

From
Christian Couder <chriscool@tuxfamily.org>
Date
Mar 13, 2009, 05:29 UTC
Message-ID
<200903130629.25452.chriscool@tuxfamily.org>
In-Reply-To
<7viqmfkuyt.fsf@gitster.siamese.dyndns.org>
Le jeudi 12 mars 2009, Junio C Hamano a écrit :
> These (except for the first one which I do not think belongs to the
> series) look more or less straightforward changes.

I added the first one to the series because I use strbuf_split with the new behavior in the series.

Show 6 quoted lines
> One worrysome thing that the series introduces is that you used to hold
> all the skipped ones in a shell variable $skip and fed it internally to
> the filter_skipped shell function, but now you give them from the command
> line.  When you have tons of skipped commits, this can easily bust the
> command line length limit on some system, while the shell may still be Ok
> with such a large string variable.

Yeah. I will send a patch (8/7) that makes "git rev-list" read the skipped commits from stdin when "--bisect-skip" is passed, and that changes git-bisect.sh accordingly. If this behavior is ok, then I can reorder the series if you want.

Show 5 quoted lines
> Because the operations in rev-list related to bisect are very closely
> tied to the implementation of the bisect Porcelain anyway, I am wondering
> if it makes more sense to just feed the name of the toplevel refname
> hierarchy, i.e. "refs/bisect", as a rev-list parameter and let rev-list
> enumerate what is skipped, which commits are good and which ones are bad.

Yeah that could be an improvement, but then the enumeration will happen once in git-bisect.sh and once in "git rev-list", instead of just once in git-bisect.sh. And we also have to deal with the other command line arguments passed to "git rev-list" on top of the enumerated commits from the refname hierachy, so I don't think that would be very consistent.

But perhaps we could create a new "git rev-bisect" builtin plumbing command that could do that. And later we could improve this new command so that it checks merge bases (like what is done in bisect_next in git-bisect.sh) and so that it also checks out the source code of the new revision to be tested (like what is done in bisect_checkout in git-bisect.sh).

Thanks, Christian.

Previous: Junio C Hamano
Message 3 of 3 in “bisect: use "rev-list --bisect-skip" and remove "filter_skipped" function”
  1. 7/7 bisect: use "rev-list --bisect-skip" and remove "filter_skipped" functionChristian Couder, Mar 12, 2009
  2. Junio C HamanoMar 12, 2009
  3. Christian CouderMar 13, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.