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)
####################################################