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

[Christian Couder <chriscool@tuxfamily.org>]

Le Friday 05 June 2009, Junio C Hamano a écrit :
> 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.

> 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.