On Sun, Mar 20, 2016 at 12:35 PM, Pranit Bauva <pranit.ba...@gmail.com> wrote: > 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
I sent the following PR 8 days ago to add something about this idea on the SoC Idea page, but unfortunately it has been merged only yesterday: https://github.com/git/git.github.io/pull/135 Also a plan like the one I outline in this PR has been discussed on the list at least a few times. As for working on --first-parent and generally speaking any project, it is a very good idea to first search the mailing list (using for example http://dir.gmane.org/gmane.comp.version-control.git/) to see if the idea has already been discussed and to link to the previous discussions in the proposal. For example you could have found this (from a few weeks ago): http://article.gmane.org/gmane.comp.version-control.git/286496/match=move+bisect+c > The major objective would be to replicate function behavior rather > than its actual implementation because what might seem to be a good > choice in bash would not be a good choice in C and vice versa. For eg. > bisect_skip() externally calls the command `git rev-list HEAD` to get > 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. This might involve a very different approach to the > existing code. To take care of this part, I will extensively debug > git-bisect.sh and the other files it depends on ie. rev-list.c, > rev-parse.c, for-each-ref.c, list_objects.c and bisect.c to study > their behavior. "builtin/bisect--helper.c" is missing from the list. > I will spend some time in testing the functions for > corner cases and running the ready-made tests to investigate its > behavior. The goal would be to produce quality code that can be > included in the next maintenance release 2.7.5. Developments like porting commands from shell to C are very unlikely to be merged in maintenance releases. > I will try to > extensively review the patches myself first and then add it on the > mailing list. I intend to discuss the whole structure of bisect.c > based on my observations in the first week. Then accordingly send > individual patches for each method. 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? I don't think it's worth worrying about that at this point in a proposal. (And you could just look at what happened during the previous GSoC to get a good idea about what happens.) > Functions I intend to cover (This is from a first-read, I haven't > actually debugged it. It might miss some technicalities or deviate > from actual) : ... I don't think such a list is very useful. At this point please focus on the big picture, that is what you call "The plan" above. > Should I also include "How git bisect works internally?" in the > proposal along with this? Yeah, I think it would help. But just show the big picture, not too many details. For example you could just tell what are the bisect related features that are implemented in the different bisect related files that you list above. > This is not my "first look" of the proposal. I am still working on the > proposal. Half way there! > > And most importantly, Would anyone like to mentor me for this project? Matthieu and myself are listed as possible mentors for the bisect related projects on the Ideas page (http://git.github.io/SoC-2016-Ideas/). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
