Re: Migrate bisect to C

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <chriscool@tuxfamily.org> writes:

> Do you mean that you want this series to migrate both "filter_skipped" and
> "check_good_are_ancestors_of_bad" to C? Or is it ok 
> if "check_good_are_ancestors_of_bad" migrates later?

One small step at a time.  That's the only sane way we can get there.

> If it is ok to migrate "check_good_are_ancestors_of_bad" later, then I think 
> something like the 8/7 patch I posted yesterday might be a good way, 

In the final shape, you will be reading from refs/bisect namespace using
for_each_ref(), and at that point you won't have anybody feeding the
skipped from the standard input.  The code you would add in [8/7] would
have to be removed if you go that route.  If you make the filter_skipped
codepath to read from for_each_ref() during this round, you can still keep
that codepath even after you fully migrate everybody to C, no?

> ...
> That means that at least one <commit-id> should always be passed to "git 
> rev-list".

But you do not have to even be tied to rev-list.  After all, the partial
migration of filter_skipped is not "git bisect in C", but more like the
first subcommand to "git bisect--helper" command that is written in C and
can be called from shell.  The next subcommand might be check_good_are...
and eventually you will have all the necessary and complex pieces the
shell version of "git bisect" currently implements as shell function as
the subcommands of "git bisect--helper".  Finally, "git bisect in C" will
then make direct calls to the functions that would implement that "git
bisect--helper" command, and gets rid of the "helper" command altogether.

	Side note.  That was how git-fetch--tool was started; it was a
	helper to partially migrate slower parts of git-fetch.sh to C.  I
	suspect we can almost remove it but not quite yet...