Re: GSOC idea: build in scripts and cleanups

[Robert David <robert.david.public@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 5248 bytes --]

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 230 bytes --]