As a advice from Jonathan Nieder. I'm sending copy of my proposal to ml. 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 user, 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. How to consider this project has success? That is pretty easy, the already done functionality will be integrated in git-add and the user usage would be consistent. 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-am, git- checkout, git-rebase. 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-7 week Start the rewriting period, this will provide some architectonic basis to be included in git-add. 5) 8-11 week Extend the C code to the state it should be. Adopt other git commands to work with the new interface correctly. Test extensively. Update documentation where needed. 6) 12 week Write more documentation, to document what was done and how. Correct 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 can't 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.