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

Re: [PATCH v2 1/3] bisect: add parameters to "filter_skipped"

From
Christian Couder <chriscool@tuxfamily.org>
Date
Jun 6, 2009, 04:38 UTC
Message-ID
<200906060638.15267.chriscool@tuxfamily.org>
In-Reply-To
<7vtz2vp45e.fsf@alter.siamese.dyndns.org>
Le Friday 05 June 2009, Junio C Hamano a écrit :
Show 21 quoted lines
> Christian Couder <chriscool@tuxfamily.org> writes:
> > because we will need to get more information from this function in
> > some later patches.
> >
> > The new "int *count" parameter gives the number of commits left after
> > the skipped commit have been filtered out.
> >
> > The new "int *skipped_first" parameter tells us if the first commit
> > in the list has been skipped. Note that using this parameter also
> > changes the behavior of the function if the first commit is indeed
> > skipped. Because we assume that in this case we will want all the
> > filtered commits, not just the first one, even if "show_all" is not
> > set.
>
> The way you use (*skipped_first == -1) as a marker to mean "we've already
> checked more than one commit_list so even when we see a one to be
> skipped, it won't be the first one" is unreadable, especially without
> explanation. Worse yet, the above paragraph explains what the parameter
> does, but why is it so special to skip the one that happens to be the
> first on the input list, especially when one does not know how the list
> is sorted to begin with.
I added the following comment before the function:
/*
 * In this function, passing a not NULL skipped_first is very special.
 * It means that we want to know if the first commit in the list is
 * skipped because we will want to test a commit away from it if it is
 * indeed skipped.
 * So if the first commit is skipped, we cannot take the shortcut to
 * just "return list" when we find the first non skipped commit, we
 * have to return a fully filtered list.
 *
 * We use (*skipped_first == -1) to mean "it has been found that the
 * first commit is not skipped". In this case *skipped_first is set back
 * to 0 just before the function returns.
 */
I hope this is enough to clarify what this function does.
Show 6 quoted lines
> I understand that the list is sorted by the "goodness" value, i.e. the
> one that cuts the graph into closer-to-equal halves comes earlier in the
> list, but still it is unclear why having to skip the best one is so
> special compared to having to skip say the second best one, especially
> when you imagine a case where the first two on the list are of equal
> "goodness" value.

The reason why only having to skip the best one is special is just because it is simpler to only check if the best one is skipped or not.

I agree that it could be an improvement to consider if other commits with the same goodness value are also skipped, but I think it would make the code more complex.

Thanks, Christian.

Previous: Junio C HamanoNext: Christian Couder
Message 4 of 9 in “automatically skip away from broken commits”
  1. 0/3 automatically skip away from broken commitsChristian Couder, Jun 5, 2009
  2. 1/3 bisect: add parameters to "filter_skipped"Christian Couder, Jun 5, 2009
  3. Junio C HamanoJun 5, 2009
  4. Christian CouderJun 6, 2009
  5. 2/3 bisect: when skipping, choose a commit away from a skipped commitChristian Couder, Jun 5, 2009
  6. Junio C HamanoJun 5, 2009
  7. Christian CouderJun 6, 2009
  8. Junio C HamanoJun 6, 2009
  9. 3/3 t6030: test skipping away from an already skipped commitChristian Couder, Jun 5, 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.