Re: GSOC idea: build in scripts and cleanups

> 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