Pranit Bauva <pranit.bauva@xxxxxxxxx> 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/ -- 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