git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: GSOC idea: build in scripts and cleanups

From
RDRobert David <robert.david.public@gmail.com>
Date
Apr 4, 2011, 07:43 UTC
Message-ID
<201104040943.10030.robert.david.public@gmail.com>
In-Reply-To
<201103301739.12691.trast@student.ethz.ch>
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) ####################################################

Previous: Robert DavidNext: Junio C Hamano
Message 9 of 20 in “GSOC idea: build in scripts and cleanups”
  1. Robert DavidMar 26, 2011
  2. Jonathan NiederMar 26, 2011
  3. Jeff KingMar 26, 2011
  4. Robert DavidMar 28, 2011
  5. Jeff KingMar 28, 2011
  6. Thomas RastMar 30, 2011
  7. Robert DavidMar 30, 2011
  8. Robert DavidApr 3, 2011
  9. Robert DavidApr 4, 2011
  10. Junio C HamanoApr 4, 2011
  11. Robert DavidApr 4, 2011
  12. Jeff KingApr 5, 2011
  13. Junio C HamanoApr 5, 2011
  14. Jeff KingApr 5, 2011
  15. Robert DavidApr 5, 2011
  16. Robert DavidApr 7, 2011
  17. Junio C HamanoApr 7, 2011
  18. Robert DavidApr 8, 2011
  19. Jonathan NiederApr 11, 2011
  20. Robert DavidApr 17, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.