I'm sending the updated proposal. I was thinking about that and realized to do the cleaning and update of git- add--interactive during GSoC and try to get that upstream (master,next). And as second part, start rewriting it into the C as longer term project. Which will lead in reviews past the GSoC during the year. Robert. ######################################################## Abstract Today git code consists of the base written in C and many helper shell or PERL scripts. While at a first time it is easier to write the script, final code is supposed to be in C. One of these scripts is git-add--interactive. Git-add--interactive is a helper script for git-add, which servers its options -i and -p. It definitely need to be integrated in git-add. Which means, dividing the script in two parts: git-add -p and git-add -i. This involves usage of some code being written already in git. Than writing some new functions common for both --patch and --interactive. And at last, fully integrating these options in git-add. But before that, it is need to clean and extend the current git-add-- interactive, to serve user needs at the best. This means for example rewrite the main part of the way the patches are chosen by use, to let the user more flexibility. Project goals Main and final project goal is integrating fully git-add--interactive into current git-add code. This task also include cleaning the functionality of this code, to make these functions more "standardized". This means consolidate the differences in these functions and make them more consistent in the user point of view. As this project is a bit longer term for GSoC period, the final from GSoC point of view will be doing the first part of the work completely (the script part) and prepare the C part as architectonic preview for ongoing review. How to consider this project has success? That is pretty easy, the cleaned and extended git-add--interactive script will be merged into the master branch. Interfaces As this is mainly part of git-add, that means that it will need to be changed at the most. There are also another commands using this functionality now: git-stash. So there is possibility that there would be some changes needs to be done to adopt new interface. I want to use as much code as possible from current git code-base, but this means further analysis to decide what exactly use and what not. Time-line The official time-line consists of 12 coding week, starting 24th May. The mid- evaluation is in the 8th week. So the plan is written in week order beginning on the first coding week. 1) Pre-coding time I will read the documentation, analyze the git-add--interactive code and possibly change some small amount of code there. To clean thinks up for upcoming work. I will also seek the git code to find out where is what, for further rewriting analyze. 2) 1-3 week Get the code of git-add--interactive cleaned and possibly written some of the consistency stuff. Analyze the code with the focus on code already written in C. 3) 4-5 week Get the cleaning and consistency stuff done. Collect the community feedback to the code, to get things improve where it is needed. 4) 6-8 week Work on the extensions to the script. Test and repair bugs, that will occur. Start the rewriting period, this will provide some architectonic basis to be included in git-add. 5) 9-11 week Collect reviews and solve bugs. Continue with the rewriting work. Test extensively. Update documentation where needed. 6) 12 week Write more documentation, to document what was done and how. Correct remaining bugs and test. About me I'm a student of second year of bachelors study on Faculty of Information Technology, Czech Technical University in Prague, Czech Republic. I have some experience with C and script languages, because I did worked for company making client software for two years. I have never contribute to open source projects, in the means of submitting patches (I did some bug-reporting in projects like midnight-commander, arch linux, debian linux). But as I love open source and use that for a long time, I realized I have to begin participating in development. Thus I see GSOC as a good startup for me. My prior experience is doing shell and PERL scripts, because I do that as "every-week" work. I work also for Prague children free-time organization, learning children open source stuff and little bit programming, mainly some small scripts (www.ddmpraha.cz). My git experience is purely user based. I use git for everyday work, administrating my computers and servers, keeping track of my school works, and my personal projects. In the past I wrote some scripts helping develop debian packages using purely git (as the software was not released yet I cant explain it further and I also don't work for that company any more. www.zonio.net). Because of GSOC start I wanted to find out more information about this proposal on git mailing list (http://article.gmane.org/gmane.comp.version- control.git/170036) ########################################################
Attachment:
signature.asc
Description: This is a digitally signed message part.