Dne pondÄlà 11 dubna 2011 08:34:44 Jonathan Nieder napsal(a): > Hi, > > Robert David wrote: > > 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. > > > 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. :) 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. > > [...] > > > 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. 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
Attachment:
signature.asc
Description: This is a digitally signed message part.