Christian Couder <chriscool@xxxxxxxxxxxxx> 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... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
