Re: GSoC Project | Improvise git bisect

Pranit Bauva [off-list ref] writes:

The project Idea: Incremental Rewrite from shell to C of git-bisect.sh

The plan:

 - Place bisect.c in builtin/
 - Implement a skeletal cmd_bisect() which will redirect to
git-bisect.sh (1e1ea69f)
 - Introduce a structure for parsing the command line flags.
 - Start converting individual functions and place it in bisect.c

The most important question is missing from this: how do you ensure that
you periodically fall back to a consistant state (i.e. a state where
your code is used and the whole testsuite passes)?

Without this, the timeline may look like:

- day 1: the 3 first steps above
- 2 months: convert individual functions
- last day: submit the whole thing

And you absolutely want to avoid this. You need to get reviewable and
mergeable code ASAP.

As I wrote earlier, I'm not convinced that your plan is the best
approach. Converting shell functions to the bisect helper is IMHO a
better first step, and having a builtin cmd_bisect can come later.

a list of commits and then store the standard output in an array as
bash can directly do the conversion, but it would not be a good thing
to do in C.

Small confusion here: there's no bash involved, just a POSIX /bin/sh
(which may, or may not point to bash), and POSIX /bin/sh has no notion
of array.

The goal would be to produce quality code that can be included in the
next maintenance release 2.7.5.

I don't think this is a candidate for a maintenance release. Maintenance
release include fixes for which we're confident enough that no
regression or unexpected behavior change will happen. Complete rewrite
is the opposite of that.

Also I am quite unsure how
the patches would be maintained by Junio. Would he create a separate
branch for me in his personal repo and then add the patches to it
without merging it to pu and then when it is completely done, the
merge will take place? Or he will individually first place every patch
in pu and the normal process?

Junio usually does not maintain branches that are not merged in pu.
"merged in pu" does not mean "accepted", just "worth paying attention".
But this implies "does not introduce obvious regression" (cf. above).

Each series is applied in its own branch, and then this branch is merged
into pu.

We consider GSoC students as normal contributors when it comes to
submitting code (that's one of the reason why Junio is not a mentor).

Should I also include "How git bisect works internally?" in the
proposal along with this?

You should include any convincing argument to support the claim that you
are able to comptlete the project. I think this includes re-explaining
in your own words how you understand bisect in its current form.

And most importantly, Would anyone like to mentor me for this project?

Christian is a potential mentor and he knows bisect very well. I can't
speak for him, but he'd probably be a good mentor for such project.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/