Re: Migrate bisect to C

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 14, 2009, 08:16 UTC
Message-ID: <7v63iccydg.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <200903140846.17599.chriscool@tuxfamily.org>

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