{"thread":{"id":"26869","subject":"GSOC idea: build in scripts and cleanups","startedAt":"2011-03-26T00:41:20Z","lastAt":"2011-04-17T18:50:27Z","messageCount":20,"participants":["Robert David","Jonathan Nieder","Jeff King","Thomas Rast","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"164345","messageId":"201103260141.20798.robert.david.public@gmail.com","threadId":"26869","inReplyTo":null,"subject":"GSOC idea: build in scripts and cleanups","fromName":"Robert David","fromEmail":"robert.david.public@gmail.com","sentAt":"2011-03-26T00:41:20Z","receivedAt":"2011-03-26T00:41:20Z","isPatch":false,"sender":{"key":"robert.david.public@gmail.com","avatar":null},"body":"Hi, \n\nI'm IT student from Czech Republic.\nI'm long time user of git and very interested in development participation. \nHaving passing your GSOC ideas, keep my eyes on scripts building in and also \ngit add -p cleanups. Because I like this kind of work. \n\nBecause there are more thinks to do in the cleanup and rewrite task, I would \nlike to ask if there is some priority in these tasks? To let me focus on the \nmost important parts. \n\nI'm experienced in C and shell ( i did a lot of bug fixing in company I worked \npart-time ) and beginner in PERL ( I wrote some scripts but nothing big ). I \nlike PERL much, so it is not a problem for me to learn that better.\n\nI was also thinking if there isn't PERL a better choice in rewriting shell \nscripts, due to planed porting (android, etc). Better than C. But I don't know \nandroid and other platform so much, so thats why I'm asking.\n\nGreets,\nRobert David.\n"},{"id":"164347","messageId":"20110326021435.GA2352@elie","threadId":"26869","inReplyTo":"201103260141.20798.robert.david.public@gmail.com","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-03-26T02:14:35Z","receivedAt":"2011-03-26T02:14:35Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(+cc: various relevant people for ideas)\nHi,\n\nRobert David wrote:\n\n> I'm long time user of git and very interested in development participation. \n\nWelcome!\n\n> Having passing your GSOC ideas, keep my eyes on scripts building in and also \n> git add -p cleanups. Because I like this kind of work. \n>\n> Because there are more thinks to do in the cleanup and rewrite task, I would \n> like to ask if there is some priority in these tasks? To let me focus on the \n> most important parts. \n\nLooking at the git-add--interactive.perl source, I see:\n\n\tprocess_args();\n\trefresh();\n\tif ($patch_mode) {\n\t\tpatch_update_cmd();\n\t}\n[...]\n\nand patch_update_cmd looks like\n\n\tmy @all_mods = list_modified($patch_mode_flavour{FILTER});\n\tmy @mods = grep { !($_->{BINARY}) } @all_mods;\n[...]\n\tif ($patch_mode) {\n\t\t@them = @mods;\n\t}\n[...]\n\tfor (@them) {\n\t\treturn 0 if patch_update_file($_->{VALUE});\n\t}\n\npatch_update_file loops over hunks in the diff for that file and acts\non them one at a time.  So a natural step might be to eliminate this\nouter \"for (@them)\" loop, so the person at the keyboard could decide\nto go back to a previous file or list all files and choose one.\n\nOthers may have more to say.  If there are things you wished \"git\ncheckout --patch\" was able to do, that can also help.\n\n> I was also thinking if there isn't PERL a better choice in rewriting shell \n> scripts, due to planed porting (android, etc). Better than C. But I don't know \n> android and other platform so much, so thats why I'm asking.\n\nSo far (on Windows and various Unixen) it seems that C is much easier\nto work with as far as porting goes.[2]\n\nJonathan\n\n[1] Android is an odd example because the platform uses Java heavily\n(so JGit might be a better fit for it).  Perhaps the wish for android\nsupport should have been put on the Eclipse ideas page[2] and a link\nadded to git's; I dunno.\n[2] http://wiki.eclipse.org/Google_Summer_of_Code_2011_Ideas#Ideas_submission\n"},{"id":"164362","messageId":"20110326133939.GB2859@sigill.intra.peff.net","threadId":"26869","inReplyTo":"20110326021435.GA2352@elie","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-26T13:39:39Z","receivedAt":"2011-03-26T13:39:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 25, 2011 at 09:14:35PM -0500, Jonathan Nieder wrote:\n\n> > I was also thinking if there isn't PERL a better choice in rewriting shell \n> > scripts, due to planed porting (android, etc). Better than C. But I don't know \n> > android and other platform so much, so thats why I'm asking.\n> \n> So far (on Windows and various Unixen) it seems that C is much easier\n> to work with as far as porting goes.[2]\n\nIf I were considering cleaning up and porting add--interactive to C, I\nthink I would probably start with just porting the \"-p\" patch loop\nfirst. I think it's the part that most people use, and most callers\ndon't support a generic \"-i\" but just the \"-p\" interface (e.g., you can\ndo \"git add -i\" or \"git add -p\", but only \"git checkout -p\"). And that\ncuts down the size of the task somewhat.\n\nAs far as cleanup versus features, I think Thomas would have to comment\non that. He is the one who did the most work on patch-mode, and\ntherefore the one who most thinks it needs cleaned up. :)\n\n> [1] Android is an odd example because the platform uses Java heavily\n> (so JGit might be a better fit for it).  Perhaps the wish for android\n> support should have been put on the Eclipse ideas page[2] and a link\n> added to git's; I dunno.\n\nYeah, I'm not sure what an Android port would quite look like. In theory\nI could probably build stock git for my rooted N1 using a\ncross-compiler. But I can't imagine what I would use it for. A native\napp seems like it would be more useful, and that pretty much requires\nJava.\n\n-Peff\n"},{"id":"164417","messageId":"201103281055.23578.robert.david.public@gmail.com","threadId":"26869","inReplyTo":"20110326133939.GB2859@sigill.intra.peff.net","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Robert David","fromEmail":"robert.david.public@gmail.com","sentAt":"2011-03-28T08:55:22Z","receivedAt":"2011-03-28T08:55:22Z","isPatch":false,"sender":{"key":"robert.david.public@gmail.com","avatar":null},"body":"Dne sobota 26 března 2011 14:39:39 Jeff King napsal(a):\n> On Fri, Mar 25, 2011 at 09:14:35PM -0500, Jonathan Nieder wrote:\n> > > I was also thinking if there isn't PERL a better choice in rewriting\n> > > shell scripts, due to planed porting (android, etc). Better than C.\n> > > But I don't know android and other platform so much, so thats why I'm\n> > > asking.\n> > \n> > So far (on Windows and various Unixen) it seems that C is much easier\n> > to work with as far as porting goes.[2]\n> \n> If I were considering cleaning up and porting add--interactive to C, I\n> think I would probably start with just porting the \"-p\" patch loop\n> first. I think it's the part that most people use, and most callers\n> don't support a generic \"-i\" but just the \"-p\" interface (e.g., you can\n> do \"git add -i\" or \"git add -p\", but only \"git checkout -p\"). And that\n> cuts down the size of the task somewhat.\n\nI have read all the code in git-add--interactive. If I understand that \ncorrect, you mean to separate -i and -p int two different commands.\nAnd make the -p option more like the -i (but just only for patching).\n\nAnd consequently port them to C. \n\n> \n> As far as cleanup versus features, I think Thomas would have to comment\n> on that. He is the one who did the most work on patch-mode, and\n> therefore the one who most thinks it needs cleaned up. :)\n> \n\nIs Thomas going to be a mentor in this task?\n\nRobert David.\n\n\n> > [1] Android is an odd example because the platform uses Java heavily\n> > (so JGit might be a better fit for it).  Perhaps the wish for android\n> > support should have been put on the Eclipse ideas page[2] and a link\n> > added to git's; I dunno.\n> \n> Yeah, I'm not sure what an Android port would quite look like. In theory\n> I could probably build stock git for my rooted N1 using a\n> cross-compiler. But I can't imagine what I would use it for. A native\n> app seems like it would be more useful, and that pretty much requires\n> Java.\n> \n> -Peff\n"},{"id":"164435","messageId":"20110328142121.GB14763@sigill.intra.peff.net","threadId":"26869","inReplyTo":"201103281055.23578.robert.david.public@gmail.com","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-28T14:21:21Z","receivedAt":"2011-03-28T14:21:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 28, 2011 at 10:55:22AM +0200, Robert David wrote:\n\n> > If I were considering cleaning up and porting add--interactive to C, I\n> > think I would probably start with just porting the \"-p\" patch loop\n> > first. I think it's the part that most people use, and most callers\n> > don't support a generic \"-i\" but just the \"-p\" interface (e.g., you can\n> > do \"git add -i\" or \"git add -p\", but only \"git checkout -p\"). And that\n> > cuts down the size of the task somewhat.\n> \n> I have read all the code in git-add--interactive. If I understand that \n> correct, you mean to separate -i and -p int two different commands.\n> And make the -p option more like the -i (but just only for patching).\n> \n> And consequently port them to C. \n\nSort of. The approach I would take would be:\n\n  1. write patch loop code in C (i.e., the code that is going to replace\n     the --patch code path from git-add--interactive.perl), and make it\n     call-able from within other C programs\n\n  2. write a new command, \"git-add--interactive-patch\", that behaves\n     like \"git-add--interactive --patch\", but is based on your new C\n     code.\n\n  3. Port C callers of \"git-add--interactive --patch\" to the new\n     interface from (1). This should be \"add -p\", \"checkout -p\", and\n     \"reset -p\".\n\n  4. Port non-C callers of \"git-add--interactive --patch\" to the new\n     command from (2). This should be git-add--interactive.perl and\n     git-stash.sh.\n\n  5. Remove the perl patch code in git-add--interactive.perl; you can\n     replace it with a call to git-add--interactive-patch.\n\nBut that doesn't mean that's the way it has to be done. Just what I\nwould do. :)\n\n> > As far as cleanup versus features, I think Thomas would have to comment\n> > on that. He is the one who did the most work on patch-mode, and\n> > therefore the one who most thinks it needs cleaned up. :)\n> \n> Is Thomas going to be a mentor in this task?\n\nI hope so. I can also co-mentor if it helps.\n\n-Peff\n"},{"id":"164692","messageId":"201103301739.12691.trast@student.ethz.ch","threadId":"26869","inReplyTo":"20110328142121.GB14763@sigill.intra.peff.net","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-03-30T15:39:12Z","receivedAt":"2011-03-30T15:39:12Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King wrote:\n> On Mon, Mar 28, 2011 at 10:55:22AM +0200, Robert David wrote:\n> \n> > > As far as cleanup versus features, I think Thomas would have to comment\n> > > on that. He is the one who did the most work on patch-mode, and\n> > > therefore the one who most thinks it needs cleaned up. :)\n> > \n> > Is Thomas going to be a mentor in this task?\n> \n> I hope so. I can also co-mentor if it helps.\n\nI'm certainly ready; I didn't propose any projects that I would not\nalso mentor.  (However, I won't mentor more than one...)\n\nNote that while it's certainly a bonus, porting it to C probably makes\nthe project more difficult and time-consuming.  We'll have to see in\nthe proposal timelines however.\n\nAs for cleanup, my gut feeling right now is that the Perl code can\nprobably cope with incremental cleanups as required for each feature.\nOn the other hand, the C port should start from a clean redesign so as\nto not rewrite it twice.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"164728","messageId":"201103302317.17855.robert.david.public@gmail.com","threadId":"26869","inReplyTo":"201103301739.12691.trast@student.ethz.ch","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Robert David","fromEmail":"robert.david.public@gmail.com","sentAt":"2011-03-30T21:17:17Z","receivedAt":"2011-03-30T21:17:17Z","isPatch":false,"sender":{"key":"robert.david.public@gmail.com","avatar":null},"body":"Dne středa 30 března 2011 17:39:12 Thomas Rast napsal(a):\n> Jeff King wrote:\n> > On Mon, Mar 28, 2011 at 10:55:22AM +0200, Robert David wrote:\n> > > > As far as cleanup versus features, I think Thomas would have to\n> > > > comment on that. He is the one who did the most work on patch-mode,\n> > > > and therefore the one who most thinks it needs cleaned up. :)\n> > > \n> > > Is Thomas going to be a mentor in this task?\n> > \n> > I hope so. I can also co-mentor if it helps.\n> \n> I'm certainly ready; I didn't propose any projects that I would not\n> also mentor.  (However, I won't mentor more than one...)\n\nThank you for your attention.\n\n> \n> Note that while it's certainly a bonus, porting it to C probably makes\n> the project more difficult and time-consuming.  We'll have to see in\n> the proposal timelines however.\n\nIt is not a big problem to me. I plan to begin full time work on this in half \nJune.\nBefore that I plan some cleanups and fixes to simplify the upcoming porting.\n\n> \n> As for cleanup, my gut feeling right now is that the Perl code can\n> probably cope with incremental cleanups as required for each feature.\n> On the other hand, the C port should start from a clean redesign so as\n> to not rewrite it twice.\n\nI agree that porting to C should be done from scratch. Thats why I would clean \nand extend the script first to make a \"preview\". Than when it will comply \nwith requirements, I will port that from scratch to C.\n\nRobert\n"},{"id":"165082","messageId":"201104032317.21573.robert.david.public@gmail.com","threadId":"26869","inReplyTo":"201103301739.12691.trast@student.ethz.ch","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Robert David","fromEmail":"robert.david.public@gmail.com","sentAt":"2011-04-03T21:17:20Z","receivedAt":"2011-04-03T21:17:20Z","isPatch":false,"sender":{"key":"robert.david.public@gmail.com","avatar":null},"body":"Dne středa 30 března 2011 17:39:12 Thomas Rast napsal(a):\n> Jeff King wrote:\n> > On Mon, Mar 28, 2011 at 10:55:22AM +0200, Robert David wrote:\n> > > > As far as cleanup versus features, I think Thomas would have to\n> > > > comment on that. He is the one who did the most work on patch-mode,\n> > > > and therefore the one who most thinks it needs cleaned up. :)\n> > > \n> > > Is Thomas going to be a mentor in this task?\n> > \n> > I hope so. I can also co-mentor if it helps.\n> \n> I'm certainly ready; I didn't propose any projects that I would not\n> also mentor.  (However, I won't mentor more than one...)\n> \n> Note that while it's certainly a bonus, porting it to C probably makes\n> the project more difficult and time-consuming.  We'll have to see in\n> the proposal timelines however.\n> \n> As for cleanup, my gut feeling right now is that the Perl code can\n> probably cope with incremental cleanups as required for each feature.\n> On the other hand, the C port should start from a clean redesign so as\n> to not rewrite it twice.\n\nHi,\n\nI have submitted the proposal on gsoc official site. I would like to ask for \nsome comments on that. I don't know how you get access to student proposals to \ngit. But I see that as proposal from \"robertdavid\" number 1.\nI would like to focus myself only on this one proposal, so that is why I'm \nasking for comments, to extend the proposal as needed.\n\nThanks,\nRobert David.\n\n"},{"id":"165095","messageId":"201104040943.10030.robert.david.public@gmail.com","threadId":"26869","inReplyTo":"201103301739.12691.trast@student.ethz.ch","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Robert David","fromEmail":"robert.david.public@gmail.com","sentAt":"2011-04-04T07:43:09Z","receivedAt":"2011-04-04T07:43:09Z","isPatch":false,"sender":{"key":"robert.david.public@gmail.com","avatar":null},"body":"As a advice from Jonathan Nieder. I'm sending copy of my proposal to ml.\n\nRobert.\n\n####################################################\nAbstract\nToday git code consists of the base written in C and many helper shell or PERL \nscripts. While at a first time it is easier to write the script, final code is \nsupposed to be in C. One of these scripts is git-add--interactive. \n\nGit-add--interactive is a helper script for git-add, which servers its options \n-i and -p. It definitely need to be integrated in git-add.\nWhich means, dividing the script in two parts: git-add -p and git-add -i. This \ninvolves usage of some code being written already in git.\nThan writing some new functions common for both --patch and --interactive. And \nat last, fully integrating these options in git-add.\n\nBut before that, it is need to clean and extend the current git-add--\ninteractive, to serve user needs at the best. \nThis means for example rewrite the main part of the way the patches are chosen \nby user, to let the user more flexibility.\n\n\nProject goals\nMain and final project goal is integrating fully git-add--interactive into \ncurrent git-add code.\nThis task also include cleaning the functionality of this code, to make these \nfunctions more \"standardized\". \nThis means consolidate the differences in these functions and make them more \nconsistent in the user point of view.\n\nHow to consider this project has success? That is pretty easy, the already \ndone functionality will be integrated in git-add and the user usage would be \nconsistent.\n\n\nInterfaces\nAs this is mainly part of git-add, that means that it will need to be changed \nat the most.\nThere are also another commands using this functionality now: git-am, git-\ncheckout, git-rebase. \nSo there is possibility that there would be some changes needs to be done to \nadopt new interface.\n\nI want to use as much code as possible from current git code-base, but this \nmeans further analysis to decide what exactly use and what not.\n\n\nTime-line \nThe official time-line consists of 12 coding week, starting 24th May. The mid-\nevaluation is in the 8th week.\nSo the plan is written in week order beginning on the first coding week. \n\n1) Pre-coding time\nI will read the documentation, analyze the git-add--interactive code and \npossibly change some small amount of code there. \nTo clean thinks up for upcoming work. I will also seek the git code to find out \nwhere is what, for further rewriting analyze.\n\n2) 1-3 week\nGet the code of git-add--interactive cleaned and possibly written some of the \nconsistency stuff.\nAnalyze the code with the focus on code already written in C.\n\n3) 4-5 week\nGet the cleaning and consistency stuff done. \nCollect the community feedback to the code, to get things improve where it is \nneeded.\n\n4) 6-7 week\nStart the rewriting period, this will provide some architectonic basis to be \nincluded in git-add.\n\n5) 8-11 week\nExtend the C code to the state it should be.\nAdopt other git commands to work with the new interface correctly.\nTest extensively.\nUpdate documentation where needed.\n\n6) 12 week\nWrite more documentation, to document what was done and how.\nCorrect bugs and test.\n\n\nAbout me\nI'm a student of second year of bachelors study on Faculty of Information \nTechnology, Czech Technical University in Prague, Czech Republic. \nI have some experience with C and script languages, because I did worked for \ncompany making client software for two years.\n\nI have never contribute to open source projects, in the means of submitting \npatches (I did some bug-reporting in projects like midnight-commander, arch \nlinux, debian linux). \nBut as I love open source and use that for a long time, I realized I have to \nbegin participating in development. Thus I see GSOC as a good startup for me.\nMy prior experience is doing shell and PERL scripts, because I do that as \n\"every-week\" work. I work also for Prague children free-time organization, \nlearning children open source stuff and little bit programming, mainly some \nsmall scripts (www.ddmpraha.cz).\n\nMy git experience is purely user based. I use git for everyday work, \nadministrating my computers and servers, keeping track of my school works, and \nmy personal projects. In the past I wrote some scripts helping develop debian \npackages using purely git (as the software was not released yet I can't \nexplain it further and I also don't work for that company any more. \nwww.zonio.net). \nBecause of GSOC start I wanted to find out more information about this proposal \non git mailing list (http://article.gmane.org/gmane.comp.version-\ncontrol.git/170036)\n####################################################\n"},{"id":"165128","messageId":"7vwrj999dv.fsf@alter.siamese.dyndns.org","threadId":"26869","inReplyTo":"201104040943.10030.robert.david.public@gmail.com","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-04T18:09:00Z","receivedAt":"2011-04-04T18:09:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robert David <robert.david.public@gmail.com> writes:\n\n> 1) Pre-coding time\n> 2) 1-3 week\n> 3) 4-5 week\n> 4) 6-7 week\n> 5) 8-11 week\n> Extend the C code to the state it should be.\n> Adopt other git commands to work with the new interface correctly.\n> Test extensively.\n> Update documentation where needed.\n>\n> 6) 12 week\n> Write more documentation, to document what was done and how.\n> Correct bugs and test.\n\nI am afraid to say that the above schedule is too ambitious and does not\nleave any time for reviews and re-rolls.  Please keep in mind that\nhistorically patch series by more experienced contributors of substantial\nsize (comparable or even smaller scale than the topic you are proposing)\nall typically took three or four review-reroll cycles, if not less, and we\ndon't automatically get extra review bandwidth just because GSoC is going\non.\n\nI am starting to suspect that it might make sense to say \"as far as GSoC\nparticipation is concerned, we would call a topic \"merged upstream\" when\nit hits 'next', even if it is not ready for 'master' at the end of the\nterm\".\n\nWhat do regular reviewers and potential mentors think?  Perhaps we have\nmore stringent quality requirements than other open source projects that\ntake \"commit first, review and fix as necessary\" cycle, and they may\ndeclare success when \"commit first\" happens.  If that is the case, 'next',\nwhose definition is \"without glaring design and implementation bugs and\nfit enough for dogfooding, but needs extra polish\", might be a better\nsuccess criteria to be fair for our students.\n\nI am not in the mentor pool and I would rather not to be to stay neutral,\nso I'll leave it up to the mentors.\n"},{"id":"165132","messageId":"201104042051.31874.robert.david.public@gmail.com","threadId":"26869","inReplyTo":"7vwrj999dv.fsf@alter.siamese.dyndns.org","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Robert David","fromEmail":"robert.david.public@gmail.com","sentAt":"2011-04-04T18:51:31Z","receivedAt":"2011-04-04T18:51:31Z","isPatch":false,"sender":{"key":"robert.david.public@gmail.com","avatar":null},"body":"Dne pondělí 04 dubna 2011 20:09:00 Junio C Hamano napsal(a):\n> Robert David <robert.david.public@gmail.com> writes:\n> > 1) Pre-coding time\n> > 2) 1-3 week\n> > 3) 4-5 week\n> > 4) 6-7 week\n> > 5) 8-11 week\n> > Extend the C code to the state it should be.\n> > Adopt other git commands to work with the new interface correctly.\n> > Test extensively.\n> > Update documentation where needed.\n> > \n> > 6) 12 week\n> > Write more documentation, to document what was done and how.\n> > Correct bugs and test.\n> \n> I am afraid to say that the above schedule is too ambitious and does not\n> leave any time for reviews and re-rolls.  Please keep in mind that\n> historically patch series by more experienced contributors of substantial\n> size (comparable or even smaller scale than the topic you are proposing)\n> all typically took three or four review-reroll cycles, if not less, and we\n> don't automatically get extra review bandwidth just because GSoC is going\n> on.\n\nThanks, this is what I wanted to hear. \nI wrote the proposal from my point of view. I'm prepared to change the size of \nthe task and schedule on mentors and developers comments.\nI'm also trying to understand your development cycle, to get that more \nprecise. But I want also say that I'm prepared for a lot of work. I have the \ntime in this period.\n\nIf I understand correctly, you mean to divide this task in more terms? And do \nless more precise. Test more, etc.\n\nRobert \n\n> \n> I am starting to suspect that it might make sense to say \"as far as GSoC\n> participation is concerned, we would call a topic \"merged upstream\" when\n> it hits 'next', even if it is not ready for 'master' at the end of the\n> term\".\n> \n> What do regular reviewers and potential mentors think?  Perhaps we have\n> more stringent quality requirements than other open source projects that\n> take \"commit first, review and fix as necessary\" cycle, and they may\n> declare success when \"commit first\" happens.  If that is the case, 'next',\n> whose definition is \"without glaring design and implementation bugs and\n> fit enough for dogfooding, but needs extra polish\", might be a better\n> success criteria to be fair for our students.\n> \n> I am not in the mentor pool and I would rather not to be to stay neutral,\n> so I'll leave it up to the mentors.\n"},{"id":"165184","messageId":"20110405165212.GB9965@sigill.intra.peff.net","threadId":"26869","inReplyTo":"201104040943.10030.robert.david.public@gmail.com","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-04-05T16:52:12Z","receivedAt":"2011-04-05T16:52:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 04, 2011 at 09:43:09AM +0200, Robert David wrote:\n\n> Today git code consists of the base written in C and many helper shell or PERL \n> scripts. While at a first time it is easier to write the script, final code is \n> supposed to be in C. One of these scripts is git-add--interactive.\n> \n> Git-add--interactive is a helper script for git-add, which servers its options \n> -i and -p. It definitely need to be integrated in git-add.\n\nCan you expand on \"definitely\" here? I.e., what are the motivations for\nthis change? I know what some of the arguments are, and I know how _I_\nwould answer the question, but I want to hear what _you_ think.\n\nAnd I am not just trying to be pedantic. Understanding the motivations\nfor a change will help us figure out the right way to go about it, and\nhow to figure out if we are successful at making it.\n\n> Interfaces\n> As this is mainly part of git-add, that means that it will need to be changed \n> at the most.\n> There are also another commands using this functionality now: git-am, git-\n> checkout, git-rebase. \n\nI don't think this is right. \"am\" and \"rebase\" have interactive modes,\nbut the code and functionality are not shared at all with\nadd--interactive. But you are missing some other commands that do have\npatch modes built on add--interactive.\n\n-Peff\n"},{"id":"165188","messageId":"20110405170729.GC9965@sigill.intra.peff.net","threadId":"26869","inReplyTo":"7vwrj999dv.fsf@alter.siamese.dyndns.org","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-04-05T17:07:30Z","receivedAt":"2011-04-05T17:07:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 04, 2011 at 11:09:00AM -0700, Junio C Hamano wrote:\n\n> Robert David <robert.david.public@gmail.com> writes:\n> \n> > 1) Pre-coding time\n> > 2) 1-3 week\n> > 3) 4-5 week\n> > 4) 6-7 week\n> > 5) 8-11 week\n> > Extend the C code to the state it should be.\n> > Adopt other git commands to work with the new interface correctly.\n> > Test extensively.\n> > Update documentation where needed.\n> >\n> > 6) 12 week\n> > Write more documentation, to document what was done and how.\n> > Correct bugs and test.\n> \n> I am afraid to say that the above schedule is too ambitious and does not\n> leave any time for reviews and re-rolls.  Please keep in mind that\n> historically patch series by more experienced contributors of substantial\n> size (comparable or even smaller scale than the topic you are proposing)\n> all typically took three or four review-reroll cycles, if not less, and we\n> don't automatically get extra review bandwidth just because GSoC is going\n> on.\n\nI agree. I think it's important to take review-reroll cycles into\naccount. Not just in terms of allocating time, but also considering the\nlatency, and keeping the student's pipeline full of work while waiting\non review.\n\nTo that end, I think it's useful to break the problem up as much as\npossible, and feed chunks to the list as quickly as possible. Even if\nyou end up with something like:\n\n  Week 2: send refactoring of functionality X\n  Week 3: build new functionality Y on top of X\n\nObviously \"Y\" is going to depend somewhat on the refactoring of \"X\". But\nyou can say in the RFC/PATCH for Y that X is still ongoing, and to\nreview with that in mind. And that keeps the student doing something\nduring week 3 while reviews for X flow in.\n\nIn the past, students haven't been very engaged with the list community,\nand I think that has hurt us. The code gets dumped as a whole at the\nend, and review is a lot harder, and GSoC is over, so the student ends\nup busy with going back to school. And the student never really learns\nthe \"normal\" way that contributors interact with the community, which\nmakes them less likely to become long-time contributors.\n\nSo I'd really like to see this year's projects breaking contributions\ninto smaller, reviewable bits and submitting over the course of the\nwhole summer.\n\n> I am starting to suspect that it might make sense to say \"as far as GSoC\n> participation is concerned, we would call a topic \"merged upstream\" when\n> it hits 'next', even if it is not ready for 'master' at the end of the\n> term\".\n\nYeah, I think that is reasonable. Stuff that makes it into \"next\" is\nusually of good quality, but just needs time to shake out bugs. Every\nonce in a while we find that something in next turns out be utter crap,\nbut usually it is obvious before it even gets merged there. Hopefully a\nstudent will be available to fix minor bugs as the topic cooks in next,\nbut if not, it is probably something the mentor can do.\n\n-Peff\n"},{"id":"165195","messageId":"7vtyecmui5.fsf@alter.siamese.dyndns.org","threadId":"26869","inReplyTo":"20110405170729.GC9965@sigill.intra.peff.net","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-05T18:18:58Z","receivedAt":"2011-04-05T18:18:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Mon, Apr 04, 2011 at 11:09:00AM -0700, Junio C Hamano wrote:\n>\n>> I am afraid to say that the above schedule is too ambitious and does not\n>> leave any time for reviews and re-rolls.  Please keep in mind that\n>> historically patch series by more experienced contributors of substantial\n>> size (comparable or even smaller scale than the topic you are proposing)\n>> all typically took three or four review-reroll cycles, if not less, and we\n>> don't automatically get extra review bandwidth just because GSoC is going\n>> on.\n>\n> I agree. I think it's important to take review-reroll cycles into\n> account. Not just in terms of allocating time, but also considering the\n> latency, and keeping the student's pipeline full of work while waiting\n> on review.\n\nDuring the course of GSoC program, one will learn that other community\nmembers do not have any obligation to keep one's pipeline full [*1*], and\nlearn how to cope with it.  Measuring the availability of others so that\none can make optimum use of others' time is a skill to be learned to be\nsuccessful in interacting with the open source community.\n\nIt takes people skills, not just \"hacking\" [*2*].\n\n>   Week 3: build new functionality Y on top of X\n>\n> Obviously \"Y\" is going to depend somewhat on the refactoring of \"X\". But\n> you can say in the RFC/PATCH for Y that X is still ongoing, and to\n> review with that in mind. And that keeps the student doing something\n> during week 3 while reviews for X flow in.\n\nYes.\n\n> In the past, students haven't been very engaged with the list community,\n> and I think that has hurt us. The code gets dumped as a whole at the\n> end, and review is a lot harder, and GSoC is over, so the student ends\n> up busy with going back to school.\n\nWhile GSoC's \"success\" criteria (from stipend payment point of view) may\nbe to finish the defined task for the project, the program's larger\nobjective is to give an opportunity to students to learn how to work with\nthe open source community, so in that sense, I'd call that a total\nfailure.\n\nI agree that we should help fixing that.\n\n[Footnote]\n\n*1* The mentor is special, has that obligation, and fulfils the obligation\nby exercising his open source community skills and guiding the student to\nbreak down the project into smaller subtasks to match the bandwidth of the\ncommunity.\n\n*2* That incidentally is what I learned from working with Linus during the\nearly 2 months of git's life.  \"People skill\" is not just \"being nice,\npolite and diplomatic\", none of which describes Linus ;-).\n\nI think the most important skills include\n\n * being observant and know what others are doing, how busy they are, what\n   patches are in flight that may have potential interactions with your\n   work, and at what velocity these patches are progressing; and\n\n * clearly communicate what you are doing, in what order, for what reason,\n   and where the boundaries of your goals are, and demonstrate that you\n   are dedicated to the cause of the project.\n\nThe former would help you avoid duplicated work (if somebody is doing what\nyou can take advantage of and it is going at a reasonable pace, you can\nspend your time on areas that do not depend on his work in the meantime\nand wait) and unnecessary conflicts. The latter would make it more likely\nthat others would want to help you by correcting flaws in your design\nassumptions and filling the gap that you are planning to punt, and help\nthese others to avoid duplicated work and unnecessary conflicts while\nhelping you.\n"},{"id":"165237","messageId":"201104060127.45773.robert.david.public@gmail.com","threadId":"26869","inReplyTo":"20110405165212.GB9965@sigill.intra.peff.net","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Robert David","fromEmail":"robert.david.public@gmail.com","sentAt":"2011-04-05T23:27:45Z","receivedAt":"2011-04-05T23:27:45Z","isPatch":false,"sender":{"key":"robert.david.public@gmail.com","avatar":null},"body":"Dne úterý 05 dubna 2011 18:52:12 Jeff King napsal(a):\n> On Mon, Apr 04, 2011 at 09:43:09AM +0200, Robert David wrote:\n> > Today git code consists of the base written in C and many helper shell or\n> > PERL scripts. While at a first time it is easier to write the script,\n> > final code is supposed to be in C. One of these scripts is\n> > git-add--interactive.\n> > \n> > Git-add--interactive is a helper script for git-add, which servers its\n> > options -i and -p. It definitely need to be integrated in git-add.\n> \n> Can you expand on \"definitely\" here? I.e., what are the motivations for\n> this change? I know what some of the arguments are, and I know how _I_\n> would answer the question, but I want to hear what _you_ think.\n\n\nFrom my point of view it means to keep the code consistent in the whole \nproject. This further means better porting, avoid duplications and thus easier \nmaintenance. And at last, I think it is my personality that takes me to \nproject like this. I like to polish things up. \n\nEven I like the PERL, I would not like to maintain project consisted in more \nprogramming languages for a long term.\n\n\n> \n> And I am not just trying to be pedantic. Understanding the motivations\n> for a change will help us figure out the right way to go about it, and\n> how to figure out if we are successful at making it.\n> \n> > Interfaces\n> > As this is mainly part of git-add, that means that it will need to be\n> > changed at the most.\n> > There are also another commands using this functionality now: git-am,\n> > git- checkout, git-rebase.\n> \n> I don't think this is right. \"am\" and \"rebase\" have interactive modes,\n> but the code and functionality are not shared at all with\n> add--interactive. But you are missing some other commands that do have\n> patch modes built on add--interactive.\n\nThanks for the notice, I will dive more deeply into it.\n\n\nI was also thinking about the timeline of this project. And maybe another \nsolution is to constantly and slowly improve git-add--interactive, to make it \naccepted in next (maybe master) on end of the SoC period. And in parallel \nwrite the C code, which would be prepared for more longer term testing and \nbugfixing to get in next. This also means for me a clear way, how to continue \ncontributing to git.\n\nRobert \n\n> \n> -Peff\n"},{"id":"165354","messageId":"201104071530.19566.robert.david.public@gmail.com","threadId":"26869","inReplyTo":"20110405165212.GB9965@sigill.intra.peff.net","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Robert David","fromEmail":"robert.david.public@gmail.com","sentAt":"2011-04-07T13:30:18Z","receivedAt":"2011-04-07T13:30:18Z","isPatch":false,"sender":{"key":"robert.david.public@gmail.com","avatar":null},"body":"I'm sending the updated proposal. \n\nI was thinking about that and realized to do the cleaning and update of git-\nadd--interactive during GSoC and try to get that upstream (master,next). \nAnd as second part, start rewriting it into the C as longer term project. \nWhich will lead in reviews past the GSoC during the year.\n\n\nRobert.\n\n########################################################\nAbstract\n\nToday git code consists of the base written in C and many helper shell or PERL \nscripts. While at a first time it is easier to write the script, final code is \nsupposed to be in C. One of these scripts is git-add--interactive. \n\nGit-add--interactive is a helper script for git-add, which servers its options \n-i and -p. It definitely need to be integrated in git-add.\nWhich means, dividing the script in two parts: git-add -p and git-add -i. This \ninvolves usage of some code being written already in git.\nThan writing some new functions common for both --patch and --interactive. And \nat last, fully integrating these options in git-add.\n\nBut before that, it is need to clean and extend the current git-add--\ninteractive, to serve user needs at the best. \nThis means for example rewrite the main part of the way the patches are chosen \nby use, to let the user more flexibility.\n\n\nProject goals\n\nMain and final project goal is integrating fully git-add--interactive into \ncurrent git-add code.\nThis task also include cleaning the functionality of this code, to make these \nfunctions more \"standardized\". \nThis means consolidate the differences in these functions and make them more \nconsistent in the user point of view.\nAs this project is a bit longer term for GSoC period, \nthe final from GSoC point of view will be doing the first part of the work \ncompletely (the script part) \nand prepare the C part as architectonic preview for ongoing review.\n\nHow to consider this project has success?\nThat is pretty easy, the cleaned and extended git-add--interactive script will \nbe merged into the master branch.\n\nInterfaces\n\nAs this is mainly part of git-add, that means that it will need to be changed \nat the most.\nThere are also another commands using this functionality now: git-stash. \nSo there is possibility that there would be some changes needs to be done to \nadopt new interface.\n\nI want to use as much code as possible from current git code-base, but this \nmeans further analysis to decide what exactly use and what not.\n\n\nTime-line \n\nThe official time-line consists of 12 coding week, starting 24th May. The mid-\nevaluation is in the 8th week.\nSo the plan is written in week order beginning on the first coding week. \n\n1) Pre-coding time\nI will read the documentation, analyze the git-add--interactive code and \npossibly change some small amount of code there. \nTo clean thinks up for upcoming work. I will also seek the git code to find out \nwhere is what, for further rewriting analyze.\n\n2) 1-3 week\nGet the code of git-add--interactive cleaned and possibly written some of the \nconsistency stuff.\nAnalyze the code with the focus on code already written in C.\n\n3) 4-5 week\nGet the cleaning and consistency stuff done. \nCollect the community feedback to the code, to get things improve where it is \nneeded.\n\n4) 6-8 week\nWork on the extensions to the script. Test and repair bugs, that will occur. \nStart the rewriting period, this will provide some architectonic basis to be \nincluded in git-add.\n\n5) 9-11 week\nCollect reviews and solve bugs.\nContinue with the rewriting work. \nTest extensively.\nUpdate documentation where needed.\n\n6) 12 week\nWrite more documentation, to document what was done and how.\nCorrect remaining bugs and test.\n\n\nAbout me\n\nI'm a student of second year of bachelors study on Faculty of Information \nTechnology, Czech Technical University in Prague, Czech Republic. \nI have some experience with C and script languages, because I did worked for \ncompany making client software for two years.\nI have never contribute to open source projects, in the means of submitting \npatches (I did some bug-reporting in projects like midnight-commander, arch \nlinux, debian linux). \nBut as I love open source and use that for a long time, I realized I have to \nbegin participating in development. Thus I see GSOC as a good startup for me.\nMy prior experience is doing shell and PERL scripts, because I do that as \n\"every-week\" work. I work also for Prague children free-time organization, \nlearning children open source stuff and little bit programming, mainly some \nsmall scripts (www.ddmpraha.cz).\n\nMy git experience is purely user based. I use git for everyday work, \nadministrating my computers and servers, keeping track of my school works, and \nmy personal projects. In the past I wrote some scripts helping develop debian \npackages using purely git (as the software was not released yet I cant explain \nit further and I also don't work for that company any more. www.zonio.net). \nBecause of GSOC start I wanted to find out more information about this proposal \non git mailing list (http://article.gmane.org/gmane.comp.version-\ncontrol.git/170036)\n########################################################\n"},{"id":"165382","messageId":"7vk4f5emcm.fsf@alter.siamese.dyndns.org","threadId":"26869","inReplyTo":"201104071530.19566.robert.david.public@gmail.com","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-07T22:19:05Z","receivedAt":"2011-04-07T22:19:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robert David <robert.david.public@gmail.com> writes:\n\n> This task also include cleaning the functionality of this code, to make these \n> functions more \"standardized\". \n> This means consolidate the differences in these functions and make them more \n> consistent in the user point of view.\n\nStandardized, consolidate, consistent are all pretty words but at the same\ntime they are highly subjective. Even though you may not have to have the\ndetailed description of everything in the proposal, you would need to at\nleast have a handful of examples of what are wrong with the current code\nin mind when making such a sweeping statement, but I cannot sense that\nfrom this proposal.\n\nWhile reading the current add-i code recently, I noticed that over time\nthe code quality deteriorated compared to the reasonably clean design in\nthe original version, perhaps due to excessive copying and mimicing,\nespecially when \"Edit patch\" feature was added and then more recently when\nnew modes to apply patches in different directions are added to allow\nother commands like \"git reset\" and \"git checkout\" to implement their\n\"--patch\" options.\n\nAn example of a clean-up in the right direction may be a patch I posted a\nfew days ago:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/170685/focus=171017 \n\nIs that the kind of \"consolidation\" you have in mind?\n\nAlso I am a bit puzzled by the inconsistency between the various stages of\nyour goals.  A clearly stated primary goal is:\n\n> Main and final project goal is integrating fully git-add--interactive into \n> current git-add code.\n\nbut the success criteria is only about the above \"This task also include\"?\n"},{"id":"165414","messageId":"201104081151.23392.robert.david.public@gmail.com","threadId":"26869","inReplyTo":"7vk4f5emcm.fsf@alter.siamese.dyndns.org","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Robert David","fromEmail":"robert.david.public@gmail.com","sentAt":"2011-04-08T09:51:22Z","receivedAt":"2011-04-08T09:51:22Z","isPatch":false,"sender":{"key":"robert.david.public@gmail.com","avatar":null},"body":"Dne pátek 08 dubna 2011 00:19:05 Junio C Hamano napsal(a):\n> Robert David <robert.david.public@gmail.com> writes:\n> > This task also include cleaning the functionality of this code, to make\n> > these functions more \"standardized\".\n> > This means consolidate the differences in these functions and make them\n> > more consistent in the user point of view.\n> \n> Standardized, consolidate, consistent are all pretty words but at the same\n> time they are highly subjective. Even though you may not have to have the\n> detailed description of everything in the proposal, you would need to at\n> least have a handful of examples of what are wrong with the current code\n> in mind when making such a sweeping statement, but I cannot sense that\n> from this proposal.\n\nWhile I have read the code, first thing I noticed is the inconsistence of \ngeneral coding standarts used. Sometimes the code is pretty nice divided into \nsubrutines to get the code understand fast, and sometimes it is a huge \nsubrutine that does as much things as possible, and thus is no so good to read \n(also I don't speak here about comments missing in a lot of code, where \nsometimes there are some). With the lack of documentation in Documentation \ndirectory, that means that this code is something like black box. And hard to \nlearn for newcomer. Tell me if Im wrong, but isnt the open-source demand also \nto let as many people ac possible to involve in development? \n\nThe biggest example is the \"patch_update_file\". Which can be divided in few \nparts. For example the \"if ($line) { ..... }\" big big box.\nThis also mean for list_and_chose and list_modified (and maybe others).\n\nSometimes there are perl like statements:\n\n\"something if|for|while|etc something\"\nand common things are written next like \n\"if (something) { something }\"\n\nIs there demand to write scripts (mainly perl) like in C to keep the code more \nreadable for C people or just write it more in perl style (to keep the code \ncleaner and shorter)?\n\nAnother thing is parsing command line options, why not use Getopt::Long here?\n\n\n\n> \n> While reading the current add-i code recently, I noticed that over time\n> the code quality deteriorated compared to the reasonably clean design in\n> the original version, perhaps due to excessive copying and mimicing,\n> especially when \"Edit patch\" feature was added and then more recently when\n> new modes to apply patches in different directions are added to allow\n> other commands like \"git reset\" and \"git checkout\" to implement their\n> \"--patch\" options.\n> \n> An example of a clean-up in the right direction may be a patch I posted a\n> few days ago:\n> \n>  \n> http://thread.gmane.org/gmane.comp.version-control.git/170685/focus=171017\n> \n> Is that the kind of \"consolidation\" you have in mind?\n\nI have read that conversation before. I also tried to reproduce that bug, but \nhave no success (in version 1.7.4.3). But before I read the code and try to \nfind something that this can occur, you send the patch. I'm not so fast as \nyou:)\n\n\n> \n> Also I am a bit puzzled by the inconsistency between the various stages of\n> \n> your goals.  A clearly stated primary goal is:\n> > Main and final project goal is integrating fully git-add--interactive\n> > into current git-add code.\n> \n> but the success criteria is only about the above \"This task also include\"?\n\nI will try to clear that up today, to finalize that in the meaning of doing the \ncleanup and extension part as part of GSoC and prepare the rewriting part for \nfurther work. I still think I can handle that and rewrite that as part of \nGSoC, but I didn't do such a big open-source project before, so I'm going to \nadopt your style of coding standards and timings. \n\nI also attach a example perl code I'm now writing, it is a half done(40%) data \n-> animated graph converter (part of my seminar work). \n\nRobert.\n\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"165602","messageId":"20110411063444.GA6608@elie","threadId":"26869","inReplyTo":"201104040943.10030.robert.david.public@gmail.com","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-11T06:34:44Z","receivedAt":"2011-04-11T06:34:44Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nRobert David wrote:\n\n> I'm sending copy of my proposal to ml.\n\nThanks, and sorry for a slow response.\n\nFull disclosure: I locally use a patch[1] to teach a --patience option\nto add -p, checkout -p, etc (to use the \"patience diff\" algorithm).  I\nnever submitted it since it wasn't clear to me how to integrate it\n(and other diff options) properly.  I will be very happy to see a\ncleaner add--interactive.\n\nSo I'm a likely early consumer of your code, although I don't think\nI'll have time to co-mentor.  Luckily there seems to be no shortage of\nwilling mentors.\n\nSome quick impressions.  This is off-the-cuff; please feel free to let\nme know if something sounds crazy.\n\n> Today git code consists of the base written in C and many helper shell or PERL \n> scripts. While at a first time it is easier to write the script, final code is \n> supposed to be in C. One of these scripts is git-add--interactive. \n[...]\n> But before that, it is need to clean and extend the current git-add--\n> interactive, to serve user needs at the best. \n\nI see two goals in tension: (1) to integrate add--interactive as C\ncode, and (2) to clean it up and change its feature set.  Either one\ncould happen without the other, and for planning it would be useful to\nknow which is going to drive decisions (e.g., what if time is short\nand something has to get cut?).\n\nIf (1) is the main goal, it might be easiest to first translate the\nexisting code, perhaps modulo small preparatory changes that make the\ntranslation easier, into C and leave major changes for afterwards.\nTracking down bugs due to a major change (like switch in\nimplementation language) is a lot easier if the pre-change version is\nwell tested and well understood.\n\nIf (2) is the main goal, it might be easiest to rewrite small parts of\nadd--interactive in C where convenient rather than rewriting the whole\nthing.  In that story, the result is a series of small patches without\nany single world-changing patch. :)\n\n[...]\n> How to consider this project has success? That is pretty easy, the already \n> done functionality will be integrated in git-add and the user usage would be \n> consistent.\n\nAfter each patch, the test suite should pass.  If some important\nfunctionality is not exercised in the test suite, ideally it can be\nadded to the test suite.  (Though that's no replacement for trying the\nchanges in day-to-day use, of course.)\n\n[...]\n> The official time-line consists of 12 coding week, starting 24th May. The mid-\n> evaluation is in the 8th week.\n> So the plan is written in week order beginning on the first coding week. \n\nJeff and Junio's advice seems sane to me.  More advice that might help\nwith writing a timeline: [2] and Christian's reply.\n\nBecause of the uncertainty I mentioned above, it's hard to give an\nexample, but an ideal proposal would include a timeline that gives a\ntechnical plan for the summer.\n\nAlso during the bonding time or even earlier it would be nice to get\nused to sending patches and reviewing them (as explained in\nDocumentation/SubmittingPatches) if you find time for it.\n\nThanks again, and hope that helps.\nJonathan\n\n[1] http://bugs.debian.org/522361\n[2] http://thread.gmane.org/gmane.comp.version-control.git/142623/focus=142877\n"},{"id":"166016","messageId":"201104172050.28441.robert.david.public@gmail.com","threadId":"26869","inReplyTo":"20110411063444.GA6608@elie","subject":"Re: GSOC idea: build in scripts and cleanups","fromName":"Robert David","fromEmail":"robert.david.public@gmail.com","sentAt":"2011-04-17T18:50:27Z","receivedAt":"2011-04-17T18:50:27Z","isPatch":false,"sender":{"key":"robert.david.public@gmail.com","avatar":null},"body":"Dne pondělí 11 dubna 2011 08:34:44 Jonathan Nieder napsal(a):\n> Hi,\n> \n> Robert David wrote:\n> > I'm sending copy of my proposal to ml.\n> \n> Thanks, and sorry for a slow response.\n\nI'm also sorry for the late response, I was off for holiday now.\n\n> \n> Full disclosure: I locally use a patch[1] to teach a --patience option\n> to add -p, checkout -p, etc (to use the \"patience diff\" algorithm).  I\n> never submitted it since it wasn't clear to me how to integrate it\n> (and other diff options) properly.  I will be very happy to see a\n> cleaner add--interactive.\n> \n> So I'm a likely early consumer of your code, although I don't think\n> I'll have time to co-mentor.  Luckily there seems to be no shortage of\n> willing mentors.\n> \n> Some quick impressions.  This is off-the-cuff; please feel free to let\n> me know if something sounds crazy.\n> \n> > Today git code consists of the base written in C and many helper shell or\n> > PERL scripts. While at a first time it is easier to write the script,\n> > final code is supposed to be in C. One of these scripts is\n> > git-add--interactive.\n> \n> [...]\n> \n> > But before that, it is need to clean and extend the current git-add--\n> > interactive, to serve user needs at the best.\n> \n> I see two goals in tension: (1) to integrate add--interactive as C\n> code, and (2) to clean it up and change its feature set.  Either one\n> could happen without the other, and for planning it would be useful to\n> know which is going to drive decisions (e.g., what if time is short\n> and something has to get cut?).\n> \n> If (1) is the main goal, it might be easiest to first translate the\n> existing code, perhaps modulo small preparatory changes that make the\n> translation easier, into C and leave major changes for afterwards.\n> Tracking down bugs due to a major change (like switch in\n> implementation language) is a lot easier if the pre-change version is\n> well tested and well understood.\n> \n> If (2) is the main goal, it might be easiest to rewrite small parts of\n> add--interactive in C where convenient rather than rewriting the whole\n> thing.  In that story, the result is a series of small patches without\n> any single world-changing patch. :)\n\nAs I updated the proposal, to focus mainly on the (2) way to go. I agree with \nyour suggestions and I think it will be part of the second round, when the \ngit-add--interactive will be done and tested enough.\n\n\n> \n> [...]\n> \n> > How to consider this project has success? That is pretty easy, the\n> > already done functionality will be integrated in git-add and the user\n> > usage would be consistent.\n> \n> After each patch, the test suite should pass.  If some important\n> functionality is not exercised in the test suite, ideally it can be\n> added to the test suite.  (Though that's no replacement for trying the\n> changes in day-to-day use, of course.)\n> \n> [...]\n> \n> > The official time-line consists of 12 coding week, starting 24th May. The\n> > mid- evaluation is in the 8th week.\n> > So the plan is written in week order beginning on the first coding week.\n> \n> Jeff and Junio's advice seems sane to me.  More advice that might help\n> with writing a timeline: [2] and Christian's reply.\n> \n> Because of the uncertainty I mentioned above, it's hard to give an\n> example, but an ideal proposal would include a timeline that gives a\n> technical plan for the summer.\n> \n> Also during the bonding time or even earlier it would be nice to get\n> used to sending patches and reviewing them (as explained in\n> Documentation/SubmittingPatches) if you find time for it.\n\nI'm planing to submit some patches as soon as it will have more time to fully \nget in the code, I think it will be something like perl style cleanups.\n\nThanks for your attention,\nRobert. \n\n> \n> Thanks again, and hope that helps.\n> Jonathan\n> \n> [1] http://bugs.debian.org/522361\n> [2]\n> http://thread.gmane.org/gmane.comp.version-control.git/142623/focus=142877\n"}]}