Re: GSOC idea: build in scripts and cleanups

Dne pondělí 11 dubna 2011 08:34:44 Jonathan Nieder napsal(a):

Hi,

Robert David wrote:

quoted

I'm sending copy of my proposal to ml.

Thanks, and sorry for a slow response.

I'm also sorry for the late response, I was off for holiday now.

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.

quoted

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.

[...]

quoted

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. :)

As I updated the proposal, to focus mainly on the (2) way to go. I agree with 
your suggestions and I think it will be part of the second round, when the 
git-add--interactive will be done and tested enough.

[...]

quoted

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

[...]

quoted

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.

I'm planing to submit some patches as soon as it will have more time to fully 
get in the code, I think it will be something like perl style cleanups.

Thanks for your attention,
Robert. 

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