Re: GSOC idea: build in scripts and cleanups

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Robert David wrote:

> I'm sending copy of my proposal to ml.

Thanks, and sorry for a slow response.

Full disclosure: I locally use a patch[1] to teach a --patience option
to add -p, checkout -p, etc (to use the "patience diff" algorithm).  I
never submitted it since it wasn't clear to me how to integrate it
(and other diff options) properly.  I will be very happy to see a
cleaner add--interactive.

So I'm a likely early consumer of your code, although I don't think
I'll have time to co-mentor.  Luckily there seems to be no shortage of
willing mentors.

Some quick impressions.  This is off-the-cuff; please feel free to let
me know if something sounds crazy.

> 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. 
[...]
> But before that, it is need to clean and extend the current git-add--
> interactive, to serve user needs at the best. 

I see two goals in tension: (1) to integrate add--interactive as C
code, and (2) to clean it up and change its feature set.  Either one
could happen without the other, and for planning it would be useful to
know which is going to drive decisions (e.g., what if time is short
and something has to get cut?).

If (1) is the main goal, it might be easiest to first translate the
existing code, perhaps modulo small preparatory changes that make the
translation easier, into C and leave major changes for afterwards.
Tracking down bugs due to a major change (like switch in
implementation language) is a lot easier if the pre-change version is
well tested and well understood.

If (2) is the main goal, it might be easiest to rewrite small parts of
add--interactive in C where convenient rather than rewriting the whole
thing.  In that story, the result is a series of small patches without
any single world-changing patch. :)

[...]
> 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.

After each patch, the test suite should pass.  If some important
functionality is not exercised in the test suite, ideally it can be
added to the test suite.  (Though that's no replacement for trying the
changes in day-to-day use, of course.)

[...]
> 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. 

Jeff and Junio's advice seems sane to me.  More advice that might help
with writing a timeline: [2] and Christian's reply.

Because of the uncertainty I mentioned above, it's hard to give an
example, but an ideal proposal would include a timeline that gives a
technical plan for the summer.

Also during the bonding time or even earlier it would be nice to get
used to sending patches and reviewing them (as explained in
Documentation/SubmittingPatches) if you find time for it.

Thanks again, and hope that helps.
Jonathan

[1] http://bugs.debian.org/522361
[2] http://thread.gmane.org/gmane.comp.version-control.git/142623/focus=142877