{"thread":{"id":"26651","subject":"Google Summer of Code 2011","startedAt":"2011-03-03T18:08:25Z","lastAt":"2011-03-25T13:02:14Z","messageCount":63,"participants":["Shawn Pearce","Jeff King","Ramkumar Ramachandra","Jakub Narebski","Jonathan Nieder","Jens Lehmann","Christian Couder","Sam Vilain","Sverre Rabbelier","Heiko Voigt","Fredrik Gustafsson","Thomas Rast","Nguyen Thai Ngoc Duy","Santi Béjar","Junio C Hamano","Alexander Miseler","Ævar Arnfjörð Bjarmason","Ilari Liusvaara","code.sculptor@gmail.com","J.H.","Pat Thoyts"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"162731","messageId":"AANLkTinpVKBjcqxaCGH0vp82kpKsO2uCBPdMoMKco6Ex@mail.gmail.com","threadId":"26651","inReplyTo":null,"subject":"Google Summer of Code 2011","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-03-03T18:08:25Z","receivedAt":"2011-03-03T18:08:25Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Anyone want to mentor this year?\n\n-- \nShawn.\n"},{"id":"162732","messageId":"20110303185918.GA18503@sigill.intra.peff.net","threadId":"26651","inReplyTo":"AANLkTinpVKBjcqxaCGH0vp82kpKsO2uCBPdMoMKco6Ex@mail.gmail.com","subject":"Re: Google Summer of Code 2011","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-03T18:59:18Z","receivedAt":"2011-03-03T18:59:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 03, 2011 at 10:08:25AM -0800, Shawn O. Pearce wrote:\n\n> Anyone want to mentor this year?\n\nI'd be happy to. I can also act as org admin this year if you want. I\nbowed out last year due to impending baby, but have no such excuse this\nyear. :)\n\nShould we also start a call for project suggestions? I haven't been\npaying attention to the GSoC timeline.\n\n-Peff\n"},{"id":"162733","messageId":"AANLkTinXZDq5FJxMmxUuWpCGgMYb3HH774eLJCojmnOz@mail.gmail.com","threadId":"26651","inReplyTo":"20110303185918.GA18503@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2011","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-03-03T19:04:51Z","receivedAt":"2011-03-03T19:04:51Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Thu, Mar 3, 2011 at 10:59, Jeff King wrote:\n> On Thu, Mar 03, 2011 at 10:08:25AM -0800, Shawn O. Pearce wrote:\n>\n>> Anyone want to mentor this year?\n>\n> I'd be happy to. I can also act as org admin this year if you want. I\n> bowed out last year due to impending baby, but have no such excuse this\n> year. :)\n\nI would appreciate that, I'm too busy this year. :-(\n\n> Should we also start a call for project suggestions? I haven't been\n> paying attention to the GSoC timeline.\n\nOrg application deadline is March 11: 23:00 UTC\n\n-- \nShawn.\n"},{"id":"162735","messageId":"20110303203323.GA21102@sigill.intra.peff.net","threadId":"26651","inReplyTo":"AANLkTinXZDq5FJxMmxUuWpCGgMYb3HH774eLJCojmnOz@mail.gmail.com","subject":"Re: Google Summer of Code 2011","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-03T20:33:23Z","receivedAt":"2011-03-03T20:33:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 03, 2011 at 11:04:51AM -0800, Shawn O. Pearce wrote:\n\n> > I'd be happy to. I can also act as org admin this year if you want. I\n> > bowed out last year due to impending baby, but have no such excuse this\n> > year. :)\n> \n> I would appreciate that, I'm too busy this year. :-(\n\nOK, there is now:\n\n https://git.wiki.kernel.org/index.php/SoC2011Application\n\nwhich is mostly just an adapted version of last year's application.\n\nI'll give people a week or so to make changes, and then do the\napplication with Google probably next Wednesday or Thursday.\n\n> > Should we also start a call for project suggestions? I haven't been\n> > paying attention to the GSoC timeline.\n> \n> Org application deadline is March 11: 23:00 UTC\n\nLooks like accepted projects are announced on the 18th, and then we\nshould be talking to students about it. So we should probably have a\nrelatively complete list of ideas by the 18th. I set up a bare-bones\nidea page here if people want to start adding ideas:\n\n https://git.wiki.kernel.org/index.php/SoC2011Ideas\n\n-Peff\n"},{"id":"162736","messageId":"20110303210419.GB27973@kytes","threadId":"26651","inReplyTo":"AANLkTinpVKBjcqxaCGH0vp82kpKsO2uCBPdMoMKco6Ex@mail.gmail.com","subject":"Re: Google Summer of Code 2011","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-03-03T21:04:25Z","receivedAt":"2011-03-03T21:04:25Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nShawn Pearce writes:\n> Anyone want to mentor this year?\n\nAlthough I'm probably not experienced enough to independently mentor a\nproject, I'd be more than happy to co-mentor, or step in if a mentor\nis suddenly unavailable. I should have a lot of time to give in\nsummer.\n\n-- Ram\n"},{"id":"162738","messageId":"m3bp1r7v94.fsf@localhost.localdomain","threadId":"26651","inReplyTo":"20110303203323.GA21102@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2011","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-03-03T21:25:16Z","receivedAt":"2011-03-03T21:25:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King writes:\n\n> On Thu, Mar 03, 2011 at 11:04:51AM -0800, Shawn O. Pearce wrote:\n> \n> > > I'd be happy to. I can also act as org admin this year if you want. I\n> > > bowed out last year due to impending baby, but have no such excuse this\n> > > year. :)\n> > \n> > I would appreciate that, I'm too busy this year. :-(\n> \n> OK, there is now:\n> \n> https://git.wiki.kernel.org/index.php/SoC2011Application\n\nQuote:\n\n \"In 2010, we had three projects: native svn support, libgit2, and a\n line level history browser.\n\n All three projects were successful. [...]\"\n\nWhat about 'integrated web client for git', aka. \"Splitting gitweb and\ndeveloping write functionalities\" project wit Pavan Kumar Sankara\n(pkumar), which failed midterm evaluations?\n\nSee https://git.wiki.kernel.org/index.php/SoC2010Projects#Splitting_gitweb_and_developing_write_functionalities_.28Integrated_web_client_for_git.29\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"162739","messageId":"20110303220826.GA6551@elie","threadId":"26651","inReplyTo":"20110303210419.GB27973@kytes","subject":"Re: Google Summer of Code 2011","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-03-03T22:08:26Z","receivedAt":"2011-03-03T22:08:26Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nRamkumar Ramachandra wrote:\n\n> Although I'm probably not experienced enough to independently mentor a\n> project, I'd be more than happy to co-mentor, or step in if a mentor\n> is suddenly unavailable. I should have a lot of time to give in\n> summer.\n\nI'd also be willing to co-mentor. Time might be a constraint, but I can\nfind time.\n\nJonathan\n"},{"id":"162740","messageId":"4D70186E.4090506@web.de","threadId":"26651","inReplyTo":"AANLkTinpVKBjcqxaCGH0vp82kpKsO2uCBPdMoMKco6Ex@mail.gmail.com","subject":"Re: Google Summer of Code 2011","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-03-03T22:38:38Z","receivedAt":"2011-03-03T22:38:38Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 03.03.2011 19:08, schrieb Shawn Pearce:\n> Anyone want to mentor this year?\n\nI can offer to either be a co-mentor (being a fill in for a mentor\nwho is not available the whole time, like I did last year for Thomas)\nor to mentor a student full time when (s)he is working on submodules.\n"},{"id":"162804","messageId":"201103050505.30860.chriscool@tuxfamily.org","threadId":"26651","inReplyTo":"AANLkTinpVKBjcqxaCGH0vp82kpKsO2uCBPdMoMKco6Ex@mail.gmail.com","subject":"Re: Google Summer of Code 2011","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2011-03-05T04:05:30Z","receivedAt":"2011-03-05T04:05:30Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Thursday 03 March 2011 19:08:25 Shawn Pearce wrote:\n> Anyone want to mentor this year?\n\nI can co-mentor this year too.\n\nThanks,\nChristian.\n"},{"id":"162853","messageId":"4D73DF82.5020900@vilain.net","threadId":"26651","inReplyTo":"AANLkTinpVKBjcqxaCGH0vp82kpKsO2uCBPdMoMKco6Ex@mail.gmail.com","subject":"Re: Google Summer of Code 2011","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2011-03-06T19:24:50Z","receivedAt":"2011-03-06T19:24:50Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Hi Shawn,\n\nOn 04/03/11 07:08, Shawn Pearce wrote:\n> Anyone want to mentor this year?\n\nThis year I'm likely to be far too busy to mentor anyone or review\napplications; however I expect to find time to deliver on my earlier\npromise to revisit GitTorrent with a series of articles and how-to's on\nthe comp.git section of my blog. I've made at least administrative\nprogress towards this goal; by setting up ikiwiki and arranging a\ndiscrete comp.git section, so that readers can follow without getting my\nother articles.\n\nThe introductory article is at\nhttp://vilain.net/comp/git/gittorrent/past_synthesis.html and I hope to\nbe able to keep producing one article a week. I would love following,\ninput, criticism etc from anyone who has been involved in the GitTorrent\nproject or its many spin-offs over the years.\n\nCheers and hope GSoC 2011 works out well for git!\nSam\n"},{"id":"162905","messageId":"AANLkTinWT8_drcfzBRQGrVj1TjsTQoUU+=-ZNJ0C1XCV@mail.gmail.com","threadId":"26651","inReplyTo":"20110303210419.GB27973@kytes","subject":"Re: Google Summer of Code 2011","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-03-07T12:15:50Z","receivedAt":"2011-03-07T12:15:50Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\n\nOn Thu, Mar 3, 2011 at 23:08, Jonathan Nieder wrote:\n> On Thu, Mar 3, 2011 at 22:04, Ramkumar Ramachandra wrote:\n>> Although I'm probably not experienced enough to independently mentor a\n>> project, I'd be more than happy to co-mentor, or step in if a mentor\n>> is suddenly unavailable. I should have a lot of time to give in\n>> summer.\n>\n> I'd also be willing to co-mentor.  Time might be a constraint, but I can\n> find time.\n\nPerhaps we can mentor a student to work on git-remote-svn with the\nthree of us? :)\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"162934","messageId":"20110307194047.GA9588@book.hvoigt.net","threadId":"26651","inReplyTo":"AANLkTinpVKBjcqxaCGH0vp82kpKsO2uCBPdMoMKco6Ex@mail.gmail.com","subject":"Re: Google Summer of Code 2011","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-03-07T19:40:47Z","receivedAt":"2011-03-07T19:40:47Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Thu, Mar 03, 2011 at 10:08:25AM -0800, Shawn Pearce wrote:\n> Anyone want to mentor this year?\n\nI can offer to mentor a project either about submodule improvements or\non gui stuff (git-gui or gitk). Since I am still not a native speaker of\nthe full git code base co-mentoring would be an option for other\nprojects.\n\nCheers Heiko\n"},{"id":"162937","messageId":"20110307205023.GB11764@paksenarrion.iveqy.com","threadId":"26651","inReplyTo":"20110307194047.GA9588@book.hvoigt.net","subject":"Re: Google Summer of Code 2011","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2011-03-07T20:50:23Z","receivedAt":"2011-03-07T20:50:23Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Mon, Mar 07, 2011 at 08:40:47PM +0100, Heiko Voigt wrote:\n> I can offer to mentor a project either about submodule improvements or\n> on gui stuff (git-gui or gitk). Since I am still not a native speaker of\n> the full git code base co-mentoring would be an option for other\n> projects.\n\nThat's sounds very interesting.\n\nI'm using git with submodules a lot (daily in 5-10 different smaller\nprojects with 1-5 developers in each) and suffers from lacking submodule\nsupport, specially in the gui-tools. \n\nBeing a student this is a part of git I would be very interested in\nhelping to improve.\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: +46 (0)733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"162984","messageId":"20110308123339.GA904@kytes","threadId":"26651","inReplyTo":"AANLkTinWT8_drcfzBRQGrVj1TjsTQoUU+=-ZNJ0C1XCV@mail.gmail.com","subject":"Re: Google Summer of Code 2011","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-03-08T12:33:45Z","receivedAt":"2011-03-08T12:33:45Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nSverre Rabbelier writes:\n> On Thu, Mar 3, 2011 at 23:08, Jonathan Nieder wrote:\n> > On Thu, Mar 3, 2011 at 22:04, Ramkumar Ramachandra wrote:\n> >> Although I'm probably not experienced enough to independently mentor a\n> >> project, I'd be more than happy to co-mentor, or step in if a mentor\n> >> is suddenly unavailable. I should have a lot of time to give in\n> >> summer.\n> >\n> > I'd also be willing to co-mentor.  Time might be a constraint, but I can\n> > find time.\n> \n> Perhaps we can mentor a student to work on git-remote-svn with the\n> three of us? :)\n\nSure, but I was hoping for an exciting new project idea- what do you\nthink?\n\n-- Ram\n"},{"id":"162986","messageId":"AANLkTikNRg9dQBrTAUrPt4wGVOW1Fro2T3jxoUPwzEnL@mail.gmail.com","threadId":"26651","inReplyTo":"20110308123339.GA904@kytes","subject":"Re: Google Summer of Code 2011","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-03-08T12:49:35Z","receivedAt":"2011-03-08T12:49:35Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Tue, Mar 8, 2011 at 13:33, Ramkumar Ramachandra wrote:\n> Sure, but I was hoping for an exciting new project idea- what do you\n> think?\n\nI don't know, having a working bidi git-remote-svn is pretty exciting\nin itself :)\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"163060","messageId":"201103091618.13638.trast@student.ethz.ch","threadId":"26651","inReplyTo":"AANLkTinpVKBjcqxaCGH0vp82kpKsO2uCBPdMoMKco6Ex@mail.gmail.com","subject":"Re: Google Summer of Code 2011","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-03-09T15:18:13Z","receivedAt":"2011-03-09T15:18:13Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Hi Shawn\n\nShawn Pearce wrote:\n> Anyone want to mentor this year?\n\nI can mentor (or co-mentor) again.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"163062","messageId":"20110309163846.GA20790@sigill.intra.peff.net","threadId":"26651","inReplyTo":"m3bp1r7v94.fsf@localhost.localdomain","subject":"Re: Google Summer of Code 2011","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-09T16:38:47Z","receivedAt":"2011-03-09T16:38:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 03, 2011 at 01:25:16PM -0800, Jakub Narebski wrote:\n\n> > OK, there is now:\n> > \n> > https://git.wiki.kernel.org/index.php/SoC2011Application\n> \n> Quote:\n> \n> \"In 2010, we had three projects: native svn support, libgit2, and a\n> line level history browser.\n> \n> All three projects were successful. [...]\"\n> \n> What about 'integrated web client for git', aka. \"Splitting gitweb and\n> developing write functionalities\" project wit Pavan Kumar Sankara\n> (pkumar), which failed midterm evaluations?\n> \n> See https://git.wiki.kernel.org/index.php/SoC2010Projects#Splitting_gitweb_and_developing_write_functionalities_.28Integrated_web_client_for_git.29\n\nThanks, I had totally forgotten about that project and didn't find it\nmentioned on the GSoC site (I guess because it failed). I couldn't find\nany discussion of its failure, though. Is there more information\nsomewhere?\n\n-Peff\n"},{"id":"163063","messageId":"20110309163952.GB20790@sigill.intra.peff.net","threadId":"26651","inReplyTo":"20110303203323.GA21102@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2011","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-09T16:39:52Z","receivedAt":"2011-03-09T16:39:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 03, 2011 at 03:33:23PM -0500, Jeff King wrote:\n\n> > I would appreciate that, I'm too busy this year. :-(\n> \n> OK, there is now:\n> \n> https://git.wiki.kernel.org/index.php/SoC2011Application\n> \n> which is mostly just an adapted version of last year's application.\n\nWe need to list a backup admin. Can I volunteer you for that (or are\nthere are volunteers)?\n\n-Peff\n"},{"id":"163064","messageId":"AANLkTi=atiU9A13L0LYXRa=MLA+2uMytA1AzLEAjFqL9@mail.gmail.com","threadId":"26651","inReplyTo":"20110309163952.GB20790@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2011","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-03-09T16:47:10Z","receivedAt":"2011-03-09T16:47:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Wed, Mar 9, 2011 at 08:39, Jeff King wrote:\n> On Thu, Mar 03, 2011 at 03:33:23PM -0500, Jeff King wrote:\n>\n>> > I would appreciate that, I'm too busy this year. :-(\n>>\n>> OK, there is now:\n>>\n>>   https://git.wiki.kernel.org/index.php/SoC2011Application\n>>\n>> which is mostly just an adapted version of last year's application.\n>\n> We need to list a backup admin. Can I volunteer you for that (or are\n> there are volunteers)?\n\nSure, I can be the backup admin.\n\n-- \nShawn.\n"},{"id":"163065","messageId":"20110309174956.GA22683@sigill.intra.peff.net","threadId":"26651","inReplyTo":"20110303203323.GA21102@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2011","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-09T17:49:56Z","receivedAt":"2011-03-09T17:49:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 03, 2011 at 03:33:23PM -0500, Jeff King wrote:\n\n> OK, there is now:\n> \n> https://git.wiki.kernel.org/index.php/SoC2011Application\n> \n> which is mostly just an adapted version of last year's application.\n> \n> I'll give people a week or so to make changes, and then do the\n> application with Google probably next Wednesday or Thursday.\n\nOur application is officially in. However, we can still edit it until\nthe deadline on Friday. If you have changes, feel free to make them on\nthe wiki page but make sure to let me know, as I have to migrate them to\nthe official application. I'll also probably do a once-over on Friday to\ncheck for any updates. If only the wiki was kept in git. :)\n\nAlso, the application links to our ideas page. Please add ideas! It will\ngive the GSoC people a sense of what we are thinking of for projects,\nand students will probably start looking at them after the list of\naccepted organizations is published (which is next Friday, the 18th).\n\n-Peff\n"},{"id":"163066","messageId":"AANLkTinpAOE06YX-m=ptQM_y-QMGpVmjewDxWopkXJkQ@mail.gmail.com","threadId":"26651","inReplyTo":"20110309174956.GA22683@sigill.intra.peff.net","subject":"Re: Google Summer of Code 2011","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-03-09T17:52:17Z","receivedAt":"2011-03-09T17:52:17Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Wed, Mar 9, 2011 at 09:49, Jeff King wrote:\n> On Thu, Mar 03, 2011 at 03:33:23PM -0500, Jeff King wrote:\n>\n>> OK, there is now:\n>>\n>>   https://git.wiki.kernel.org/index.php/SoC2011Application\n>>\n>> which is mostly just an adapted version of last year's application.\n>>\n>> I'll give people a week or so to make changes, and then do the\n>> application with Google probably next Wednesday or Thursday.\n>\n> Our application is officially in. However, we can still edit it until\n> the deadline on Friday. If you have changes, feel free to make them on\n> the wiki page but make sure to let me know, as I have to migrate them to\n> the official application. I'll also probably do a once-over on Friday to\n> check for any updates. If only the wiki was kept in git. :)\n>\n> Also, the application links to our ideas page. Please add ideas! It will\n> give the GSoC people a sense of what we are thinking of for projects,\n> and students will probably start looking at them after the list of\n> accepted organizations is published (which is next Friday, the 18th).\n\nThe ideas page is very important. Git needs a good set of ideas on its\nideas page in order to be accepted. Google has stated this many times\nin the past, its a key part of the decision making process (not the\nonly part, but an important part nonetheless).\n\nWe should have a good ideas page by the application deadline, so that\nwhen Google goes to review applications, they can at least make a fair\nassessment of our ideas list.\n\n-- \nShawn.\n"},{"id":"163093","messageId":"20110309215255.GA11845@book.hvoigt.net","threadId":"26651","inReplyTo":"20110307205023.GB11764@paksenarrion.iveqy.com","subject":"Re: Re: Google Summer of Code 2011","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-03-09T21:52:56Z","receivedAt":"2011-03-09T21:52:56Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Mon, Mar 07, 2011 at 09:50:23PM +0100, Fredrik Gustafsson wrote:\n> On Mon, Mar 07, 2011 at 08:40:47PM +0100, Heiko Voigt wrote:\n> > I can offer to mentor a project either about submodule improvements or\n> > on gui stuff (git-gui or gitk). Since I am still not a native speaker of\n> > the full git code base co-mentoring would be an option for other\n> > projects.\n> \n> That's sounds very interesting.\n> \n> I'm using git with submodules a lot (daily in 5-10 different smaller\n> projects with 1-5 developers in each) and suffers from lacking submodule\n> support, specially in the gui-tools. \n> \n> Being a student this is a part of git I would be very interested in\n> helping to improve.\n\nSounds promising. When I was talking about gui or submodules I did not\nthink about gui *and* submodules. Do you have some concrete areas you\nwould like to improve in mind?\n\nCheers Heiko\n"},{"id":"163094","messageId":"20110309215841.GC4400@sigill.intra.peff.net","threadId":"26651","inReplyTo":"AANLkTinpAOE06YX-m=ptQM_y-QMGpVmjewDxWopkXJkQ@mail.gmail.com","subject":"Summer of Code project ideas due this Friday","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-09T21:58:41Z","receivedAt":"2011-03-09T21:58:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 09, 2011 at 09:52:17AM -0800, Shawn O. Pearce wrote:\n\n> The ideas page is very important. Git needs a good set of ideas on its\n> ideas page in order to be accepted. Google has stated this many times\n> in the past, its a key part of the decision making process (not the\n> only part, but an important part nonetheless).\n> \n> We should have a good ideas page by the application deadline, so that\n> when Google goes to review applications, they can at least make a fair\n> assessment of our ideas list.\n\nThen let's repeat it with a more eye-catching subject, and cc all of the\npeople who have said they would mentor so far.\n\nFor those just joining us:\n\nThe Google Summer of Code application deadline is this Friday (March 11)\nat 23:00 UTC. They will be looking at our ideas page at:\n\n https://git.wiki.kernel.org/index.php/SoC2011Ideas\n\nIf you have any ideas, please add them to the page! Whether you are\navailable to mentor the project, or simply think it would make a good\nproject and want to inspire others to mentor it, it's appropriate to go\nthere.\n\n-Peff\n"},{"id":"163098","messageId":"20110309231604.GA3903@paksenarrion.iveqy.com","threadId":"26651","inReplyTo":"20110309215255.GA11845@book.hvoigt.net","subject":"Re: Re: Google Summer of Code 2011","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2011-03-09T23:16:04Z","receivedAt":"2011-03-09T23:16:04Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Wed, Mar 09, 2011 at 10:52:56PM +0100, Heiko Voigt wrote:\n> Hi,\n> \n> On Mon, Mar 07, 2011 at 09:50:23PM +0100, Fredrik Gustafsson wrote:\n> > On Mon, Mar 07, 2011 at 08:40:47PM +0100, Heiko Voigt wrote:\n> > > I can offer to mentor a project either about submodule improvements or\n> > > on gui stuff (git-gui or gitk). Since I am still not a native speaker of\n> > > the full git code base co-mentoring would be an option for other\n> > > projects.\n> > \n> > That's sounds very interesting.\n> > \n> > I'm using git with submodules a lot (daily in 5-10 different smaller\n> > projects with 1-5 developers in each) and suffers from lacking submodule\n> > support, specially in the gui-tools. \n> > \n> > Being a student this is a part of git I would be very interested in\n> > helping to improve.\n> \n> Sounds promising. When I was talking about gui or submodules I did not\n> think about gui *and* submodules. Do you have some concrete areas you\n> would like to improve in mind?\n\nMany of the ideas I had was already mentioned in \nhttps://github.com/jlehmann/git-submod-enhancements/wiki/\n\nThe ones I feel is most important for me is:\n* gitk: Add popup menu for submodules to see the detailed history of\nchanges\n* Check before a push in the superproject that all submodules HEADs are\npushed\n* Showing that a submodule has a HEAD not on any branch in “git status”\n* Move the submodules git directories into the superproject’s .git so that\nsubmodules can be created and deleted\n\nWith this said, I'm not familiar with the git codebase yet and does not\nhave any concrete solutions. For example, I don't understand why a\nsubmodule doesn't get a default branch.\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"163100","messageId":"20110310001017.GA24169@elie","threadId":"26651","inReplyTo":"20110309215841.GC4400@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-03-10T00:10:17Z","receivedAt":"2011-03-10T00:10:17Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJeff King wrote:\n\n> If you have any ideas, please add them to the page!\n\nThanks for a pointer. Some ideas still at the \"throw them against the\nwall and see if they stick\" stage: please feel free to add to the page\nif you think you can find subsets with the right scope. Later today I\ncan look more carefully.\n\n1. Cross-compilable msysgit: ideally, allowing someone to run\n \"make msysgit-installer\" on Linux from an msysgit-source.git repo\n to get an installer. Nice subsets to start with might be msys.dll\n (I think there has been some work on that already) and the basic\n msys utilities.\n\n2. Merge libgit2 into git.git: polish the existing code in libgit2 so\n that standard git can use it. Presumably this would happen by\n porting one function at a time, not by making git link to libgit2\n immediately. People familiar with libgit2 might be able to pick\n out particularly interesting subsets to start with (diff\n generation?).\n\n3. Remote helpers: bidi git remote-svn (or one-way remote-hg, or\n remote-cvs, or ...).\n\n4. filter-branch killer: using fast-import's new features to implement\n common filter-branch operations (--subdirectory-filter,\n --prune-empty, obliterating certain files) faster.\n\n5. rev-list: Coping with timeskew.\n\n6. shallow clone: Push support.\n\n7. fixing workdirs (and alternates), along the lines explained in the\n thread .\n I would be very much interested in this.\n\n7. packfilev4.\n"},{"id":"163101","messageId":"AANLkTimHC3Wfqd4AbLDGuf17wEisTRutMc2VL+S=s2nM@mail.gmail.com","threadId":"26651","inReplyTo":"20110309215841.GC4400@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-10T00:19:36Z","receivedAt":"2011-03-10T00:19:36Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Mar 10, 2011 at 4:58 AM, Jeff King wrote:\n> They will be looking at our ideas page at:\n>\n>    https://git.wiki.kernel.org/index.php/SoC2011Ideas\n>\n> If you have any ideas, please add them to the page!\n\nJeff, how is the \"support multiple transport (torrent, bundle, http..)\ncloning\" going? The one that you were working on from the \"initial\nclone from bundle\" thread? Is it ok to make it a SoC project\n(presumably with at least bundle clone support)?\n-- \nDuy\n"},{"id":"163152","messageId":"20110310163011.GA17137@sigill.intra.peff.net","threadId":"26651","inReplyTo":"20110310001017.GA24169@elie","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-10T16:30:11Z","receivedAt":"2011-03-10T16:30:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 09, 2011 at 06:10:17PM -0600, Jonathan Nieder wrote:\n\n> 2. Merge libgit2 into git.git: polish the existing code in libgit2 so\n> that standard git can use it. Presumably this would happen by\n> porting one function at a time, not by making git link to libgit2\n> immediately. People familiar with libgit2 might be able to pick\n> out particularly interesting subsets to start with (diff\n> generation?).\n\nThat's definitely bigger than a SoC project at this point. However, one\nsmaller project might be to start implementing a subset of git commands\n(probably plumbing) on top of libgit2, and then see how well the result\npasses git.git tests.\n\n> 4. filter-branch killer: using fast-import's new features to implement\n> common filter-branch operations (--subdirectory-filter,\n> --prune-empty, obliterating certain files) faster.\n\nYeah, I like that. Or maybe somebody can pick up git-sequencer, which in\ntheory could be used to filter-branch, too (or maybe sequencer can go on\ntop of fast-import? :) ).\n\n> 5. rev-list: Coping with timeskew.\n\nI don't think this is big enough for a SoC project. It's on my todo list\nfor the near-term, though.\n\n> 7. packfilev4.\n\nI suspect that is too complex for a SoC project. But you never know.\n\n-Peff\n"},{"id":"163153","messageId":"20110310163101.GB17137@sigill.intra.peff.net","threadId":"26651","inReplyTo":"AANLkTimHC3Wfqd4AbLDGuf17wEisTRutMc2VL+S=s2nM@mail.gmail.com","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-10T16:31:01Z","receivedAt":"2011-03-10T16:31:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 10, 2011 at 07:19:36AM +0700, Nguyen Thai Ngoc Duy wrote:\n\n> On Thu, Mar 10, 2011 at 4:58 AM, Jeff King wrote:\n> > They will be looking at our ideas page at:\n> >\n> >    https://git.wiki.kernel.org/index.php/SoC2011Ideas\n> >\n> > If you have any ideas, please add them to the page!\n> \n> Jeff, how is the \"support multiple transport (torrent, bundle, http..)\n> cloning\" going? The one that you were working on from the \"initial\n> clone from bundle\" thread? Is it ok to make it a SoC project\n> (presumably with at least bundle clone support)?\n\nI pushed it back in favor of other topics, but I will get to it\neventually. If you want to make a SoC proposal, go for it. Though I\nthink it might not be big enough by itself, and might need to be folded\ninto a larger project.\n\n-Peff\n"},{"id":"163157","messageId":"201103101815.23477.trast@student.ethz.ch","threadId":"26651","inReplyTo":"20110310001017.GA24169@elie","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-03-10T17:15:23Z","receivedAt":"2011-03-10T17:15:23Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jonathan Nieder wrote:\n> Thanks for a pointer. Some ideas still at the \"throw them against the\n> wall and see if they stick\" stage: please feel free to add to the page\n> if you think you can find subsets with the right scope.\n\nSome stuff off the top of my head, please apply a similar filter:\n\n* Word-based merge helper\n\n The existing merge algorithms are all tailored to line-based formats\n such as code. Writing, e.g., LaTeX or even asciidoc requires\n sticking to a strict word-wrapped format. Worse even, re-wrapping\n leads to headaches if people work on the same areas a lot, much like\n the effects of code reindents.\n\n Something similar was already proposed in 2010, IIRC by Dscho:\n\n https://git.wiki.kernel.org/index.php/SoC2010Ideas#Merge_helper_for_LaTeX_files\n\n One possible angle of attack given --word-diff=porcelain would be:\n\n 1. Fix --word-diff to properly represent both sides of the diff at\n least optionally. (It was observed in a list post some months\n ago that it doesn't even represent *one* side faithfully.)\n\n 2. Use --word-diff=porcelain as input to some to-be-written merge\n algorithm.\n\n\n\n* Clean up add -p\n\n git-add--interactive.perl became a bit of a mess. Partly due to my\n own efforts with {checkout,stash,...} it has bolted-on interfaces to\n other commands. There are some UI issues that simply fall out of\n its design, e.g., you cannot go back from one file to another,\n Ctrl-C stops applying to the current file but does not discard\n earlier files, etc. And that's not saying anything about 'add -i'\n which I don't really know.\n\n This would probably not be a very fun project, but it could add a\n little edge of usability to the tool and it's probably one of the\n few pure-Perl ideas we can offer.\n\n\n\n> 4. filter-branch killer: using fast-import's new features to implement\n> common filter-branch operations (--subdirectory-filter,\n> --prune-empty, obliterating certain files) faster.\n\nI would phrase this as follows:\n\n* fast-import-filter\n\n Implement a utility that can execute certain transformations to\n fast-import streams, such as:\n\n - delete or rename entire files/directories\n - split out subtrees\n - ...\n\n Ideally, this should be a thin command line interface around a set\n of primitives (such as a Perl package) that allow a competent\n scripter to go beyond the CLI. (There have been threads on this.)\n\n Later on, make an interface that automatically does\n\n git fast-export | fast-import-filter | git fast-import\n\n with suitable options. Nice because it should be largely orthogonal\n to everything except the fast-import stream format.\n\nIn addition, Jeff wrote:\n> Yeah, I like that. Or maybe somebody can pick up git-sequencer, which in\n> theory could be used to filter-branch, too (or maybe sequencer can go on\n> top of fast-import? :) ).\n\nI'd be interested to hear how that goes, because I think the tools are\nfundamentally different. The rebase and thus sequencer family is\ndelta-based, and the fast-import and filter-branch families are\ntree-based. Feel free to prove me wrong of course.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"163158","messageId":"AANLkTinv-CQ4TKQu8T8o6K5aJ3ivdrScPN0shF=ma9Oz@mail.gmail.com","threadId":"26651","inReplyTo":"20110310163011.GA17137@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-03-10T17:31:23Z","receivedAt":"2011-03-10T17:31:23Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Thu, Mar 10, 2011 at 08:30, Jeff King wrote:\n>\n>> 7. packfilev4.\n>\n> I suspect that is too complex for a SoC project. But you never know.\n\nIt is. Nico is also probably working on it.\n\nMy big concern with pack v4 right now is the on-disk format of\ncommits/trees is different from the current wire protocol. If a pack\nv2 only client connected to a server using pack v4, the server would\nhave to spend a lot of time to inflate/deflate about 60% of the\nobjects in the repository (commits and trees). That is a lot of CPU\ntime. So even if a SoC-er finished the work, it probably wouldn't be\nmerged because of this penalty.\n\n-- \nShawn.\n"},{"id":"163159","messageId":"m339mu7u6n.fsf@localhost.localdomain","threadId":"26651","inReplyTo":"20110310001017.GA24169@elie","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-03-10T17:39:45Z","receivedAt":"2011-03-10T17:39:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jonathan Nieder writes:\n\n> 4. filter-branch killer: using fast-import's new features to implement\n> common filter-branch operations (--subdirectory-filter,\n> --prune-empty, obliterating certain files) faster.\n\nHow it would be different from existing reposurgeon tool by ESR\n(cross-VC thanks to using fast-import format), or git_fast_filter by\nElijah Newren (more of a library than a ready tool)?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"163162","messageId":"AANLkTim9a89WZdMBYWjTH0p_SR+cy80ndogGJeguKxyE@mail.gmail.com","threadId":"26651","inReplyTo":"201103101815.23477.trast@student.ethz.ch","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2011-03-10T18:17:31Z","receivedAt":"2011-03-10T18:17:31Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Thu, Mar 10, 2011 at 6:15 PM, Thomas Rast wrote:\n> Jonathan Nieder wrote:\n>> Thanks for a pointer.  Some ideas still at the \"throw them against the\n>> wall and see if they stick\" stage: please feel free to add to the page\n>> if you think you can find subsets with the right scope.\n>\n> Some stuff off the top of my head, please apply a similar filter:\n>\n> * Word-based merge helper\n>\n>  The existing merge algorithms are all tailored to line-based formats\n>  such as code.  Writing, e.g., LaTeX or even asciidoc requires\n>  sticking to a strict word-wrapped format.  Worse even, re-wrapping\n>  leads to headaches if people work on the same areas a lot, much like\n>  the effects of code reindents.\n\nNot a complete/right solution (and not even extensively tested), but I\ndid a \"trivial\" merge program for LaTeX files that:\n\n1.- Rewraps all files as the first one, using dwdiff\n2.- Perform a normal line based merge\n\n[wlmerge]\n#!/bin/bash\ntmp1=$(mktemp -t wlmerge.XXXXXXX)\ntmp2=$(mktemp -t wlmerge.XXXXXXX)\ntrap \"rm -f $tmp1 $tmp2\" 0 1 2 3 15\n[ ! -e \"$1\" ] && exit 1\nfile1=$1 && shift\n[ ! -e \"$1\" ] && exit 1\norig=$1 && shift\n[ ! -e \"$1\" ] && exit 1\nfile2=$1 && shift\ndwdiff -2 -w \"\" -x \"\" \"$orig\" \"$file1\" > $tmp1\ndwdiff -2 -w \"\" -x \"\" \"$file2\" \"$file1\" > $tmp2\nmerge \"$file1\" $tmp1 $tmp2\n\nI even have a \"wldiff\", but nowadays I use --color-words exclusively!\n\nHTH,\nSanti\n"},{"id":"163164","messageId":"20110310184653.GA17832@sigill.intra.peff.net","threadId":"26651","inReplyTo":"201103101815.23477.trast@student.ethz.ch","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-10T18:46:53Z","receivedAt":"2011-03-10T18:46:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 10, 2011 at 06:15:23PM +0100, Thomas Rast wrote:\n\n> * Clean up add -p\n> \n> git-add--interactive.perl became a bit of a mess. Partly due to my\n> own efforts with {checkout,stash,...} it has bolted-on interfaces to\n> other commands. There are some UI issues that simply fall out of\n> its design, e.g., you cannot go back from one file to another,\n> Ctrl-C stops applying to the current file but does not discard\n> earlier files, etc. And that's not saying anything about 'add -i'\n> which I don't really know.\n> \n> This would probably not be a very fun project, but it could add a\n> little edge of usability to the tool and it's probably one of the\n> few pure-Perl ideas we can offer.\n\nOne more wishlist item for this. I use \"add -p\" for almost all of my\nadds these days, because I like the final review check. So after a\nconflicted merge, I find myself doing \"add -p\" to stage my resolution.\nThe current behavior is that it shows the --cc diff and exits. It would\nbe cool to handle staging the resolution, which would involve converting\nthe combined diff into something that can be applied.\n\n> I'd be interested to hear how that goes, because I think the tools are\n> fundamentally different. The rebase and thus sequencer family is\n> delta-based, and the fast-import and filter-branch families are\n> tree-based. Feel free to prove me wrong of course.\n\nHmm, yeah, that is a fundamental difference. It might be possible to\novercome it, but I admit I haven't really given it any thought yet at\nthis point.\n\n-Peff\n"},{"id":"163166","messageId":"7vpqpy4w8k.fsf@alter.siamese.dyndns.org","threadId":"26651","inReplyTo":"20110310184653.GA17832@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-10T19:21:47Z","receivedAt":"2011-03-10T19:21:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> One more wishlist item for this. I use \"add -p\" for almost all of my\n> adds these days, because I like the final review check. So after a\n> conflicted merge, I find myself doing \"add -p\" to stage my resolution.\n> The current behavior is that it shows the --cc diff and exits. It would\n> be cool to handle staging the resolution, which would involve converting\n> the combined diff into something that can be applied.\n\nI think the end-result would be a nice feature. I suspect that it would\nnot involve conversion from --cc, but more like using the difference\nbetween the HEAD and the working tree, generated as if there is no\nmulti-stage index.\n"},{"id":"163168","messageId":"20110310192851.GB19257@sigill.intra.peff.net","threadId":"26651","inReplyTo":"7vpqpy4w8k.fsf@alter.siamese.dyndns.org","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-10T19:28:51Z","receivedAt":"2011-03-10T19:28:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 10, 2011 at 11:21:47AM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > One more wishlist item for this. I use \"add -p\" for almost all of my\n> > adds these days, because I like the final review check. So after a\n> > conflicted merge, I find myself doing \"add -p\" to stage my resolution.\n> > The current behavior is that it shows the --cc diff and exits. It would\n> > be cool to handle staging the resolution, which would involve converting\n> > the combined diff into something that can be applied.\n> \n> I think the end-result would be a nice feature. I suspect that it would\n> not involve conversion from --cc, but more like using the difference\n> between the HEAD and the working tree, generated as if there is no\n> multi-stage index.\n\nThe trouble is that I would like to see the combined diff, then say \"OK\"\nand have it apply the result to the index. But because we work on a\nper-hunk basis, you need to match the combined diff hunks to the regular\ndiff hunks, taking into account that hunks could be split. Which maybe\nis straightforward, but I haven't convinced myself yet that there are no\ncorner cases where they don't line up.\n\nI guess one could argue that I should be using mergetool, and making a\nmergetool helper that is more like \"add -p\" (show hunks, say \"choose\nleft, choose right, choose none\"). But I generally fix up the conflict\nusing an editor and just want \"add -p\" as a final check.\n\nI'll probably look into it more eventually, but it's not a high priority\nat this point.\n\n-Peff\n"},{"id":"163172","messageId":"7vtyfa3ddm.fsf@alter.siamese.dyndns.org","threadId":"26651","inReplyTo":"20110310192851.GB19257@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-10T20:54:29Z","receivedAt":"2011-03-10T20:54:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> I think the end-result would be a nice feature. I suspect that it would\n>> not involve conversion from --cc, but more like using the difference\n>> between the HEAD and the working tree, generated as if there is no\n>> multi-stage index.\n>\n> The trouble is that I would like to see the combined diff, then say \"OK\"\n> and have it apply the result to the index. But because we work on a\n> per-hunk basis, you need to match the combined diff hunks to the regular\n> diff hunks, taking into account that hunks could be split. Which maybe\n> is straightforward, but I haven't convinced myself yet that there are no\n> corner cases where they don't line up.\n\nForgetting for now the implementation, I _think_ what you would want is\nfor \"git add -p\" to notice that you are resolving conflicts, and do not\nbother you about cleanly merged parts (I take it is a given that you would\nalways want to add them to the index without even inspecting when running\n\"add -p\"), and make the per-hunk selection loop ask only about the parts\nthat originally had conflicts.\n\nBut it is rather hard to arrange. Neither \"--cc\" nor \"-c\" during the\nmerge is about showing conflicts but is about showing the result with\nrespect to the two originals. If you resolved conflicts in your editor\nalready, there are no lines with \"<<>>\" markers that are different from\neither original to cause the \"conflicted parts\" to appear in their output.\nIf your conflict resolution ended up in taking what one side did, \"--cc\"\nwill hide it as a non-event. So at least you would be using \"-c\" to\nimplement this.\n\nAlso, you have to remember that \"add -p\" is about adding the state you\ndeem Ok incrementally to the index, that once you add a path to the index\nthe higher stages for the path will collapse to stage #0, and that \"-c\"\nand \"--cc\" make their comparison based on what you have in higher stages.\n\nI would imagine that a workable implementation might look like this:\n\n 0. The solution introduces a new index extension, \"PRSF\" (partial\n resolution so far)\". This is a mapping from pathname to a blob object\n name.\n\n 1. \"git add -p\" notices that you are in the middle of conflict\n resolution, by noticing that you have higher stages to the path.\n\n 2. Look up the path from the PRSF extension. If there is no entry for\n the path, recreate the content-level 3-way merge using the content of\n three stages (i.e. the state immediately after the mergy operation\n that caused the conflicts before you touched the corresponding file in\n your working tree), and register this image (with the full glory of\n \"<<>>\" conflict markers) to the extension. If there already is an\n entry in the extension for the path, skip this step.\n\n 3. The patch the user will see in the interactive hunk selection is the\n difference between the working tree and the PRSF image, not your\n regular index (nor the HEAD version). This allows you to see how you\n resolved the conflict incrementally so far.\n\n 4. Choosing a hunk to \"apply\" would not affect the index entry for the\n path, as it would collapse its higher stages. It instead updates the\n blob registered in the PRSF extension using the hunk you are applying.\n\nIf you are running \"git add -p\" incrementally (i.e. edit a little, review\nwith diff, then \"add -p\" the part you are sure about, and repeat the whole\nthing), the next invocation of \"git add -p\" would notice that you still\nhave unresolved conflicts in PRSF. It will skip the step 2 above and the\nstep 3 will let you review the remaining difference between the PRSF image\n(which you updated in step 4 during the last round) and what you have in\nthe working tree. The step 4 will update the PRSF image for the next\ninvocation of \"git add -p\". And you continue until you are done.\n\nAt the end (we would probably need a good way to detect the user might\nwant to declare \"end\" automatically for a good user experience), use the\nPRSF image to collapse the higher stages for the path down to stage 0.\n"},{"id":"163174","messageId":"4D794531.40205@miseler.de","threadId":"26651","inReplyTo":"20110309215841.GC4400@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Alexander Miseler","fromEmail":"alexander@miseler.de","sentAt":"2011-03-10T21:40:01Z","receivedAt":"2011-03-10T21:40:01Z","isPatch":false,"sender":{"key":"alexander@miseler.de","avatar":null},"body":"Comments on the \"Better big-file support\" section:\n\n\n\"While git can handle arbitrary-sized binary content [...]\"\n\nThis is very much not true. Git tries at many places to load the complete file into memory and usually fails with \"out of memory\" if it can't. With the 32bit msysGit client this places the upper file size limit, from purely empirical observation, at 600-700 MByte. When a file is to large git fails late, adding and committing works (as long as there are no filters or other complications), but you can forget about pushing, rebasing or otherwise manipulating that commit. Even worse yet, commits consisting of smaller files but with a combined size over the limit will also cause out-of-memories.\n\nThus a main focus should be the memory problem, e.g. by using stream-like file handling everywhere, since not working at all is orders of magnitude worse than working slowly :)\n\n\n\n\"In some cases, this may be as simple as having a \"large file\" codepath that avoids pulling whole files into memory (e.g., during \"git add\").\"\n\nIronically git add is one of the few things that work with large files, as mentioned above. Presumably the stream-oriented zlib enforced/encouraged a steam-like handling here :)\nSlow as hell though and of course it is usually not sensible to compress a 1.5 GByte file.\n\n\n\n\nI'm very willing to work on this topic. Though I'm not a student and as a git code newbie I also don't have the skills for mentoring yet.\n"},{"id":"163175","messageId":"20110310214206.GA15828@sigill.intra.peff.net","threadId":"26651","inReplyTo":"7vtyfa3ddm.fsf@alter.siamese.dyndns.org","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-10T21:42:06Z","receivedAt":"2011-03-10T21:42:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 10, 2011 at 12:54:29PM -0800, Junio C Hamano wrote:\n\n> Forgetting for now the implementation, I _think_ what you would want is\n> for \"git add -p\" to notice that you are resolving conflicts, and do not\n> bother you about cleanly merged parts (I take it is a given that you would\n> always want to add them to the index without even inspecting when running\n> \"add -p\"), and make the per-hunk selection loop ask only about the parts\n> that originally had conflicts.\n\nYes, I don't want to see cleanly merged parts. And \"--cc\" already does\nwhat I want by not showing them. But of course they still need to be\nadded to the index.\n\nSo my thinking was more along the lines of:\n\n 1. Get \"git diff HEAD file\" and store its hunks.\n\n 2. Get \"git diff --cc file\" and stores its hunks.\n\n 3. For each hunk in (1), if it does not have an analagous hunk in (2),\n mark it for staging without asking the user.\n\n 4. For the remaining hunks in (1), show the user the analagous --cc\n hunk from (2), and mark the hunk from (1) for staging if requested.\n\n 5. Create the final patch from the marked hunks, apply it to\n HEAD:file, and put that in the index.\n\nThere are two issues (and I think you know this, but it took me\nreasoning out why this wouldn't work to quite understand what you were\nsaying in your email, so I'll elaborate here for the benefit of other\nreaders):\n\n a. Step (3) glosses over the definition of \"analagous hunk\". In simple\n cases the hunk headers match up (i.e., they start at the same\n offsets). But the --cc diff is actually a diff against the merge\n base, and the diff in step (1) is against HEAD. So actually we\n would want step (1) and (5) to deal not with the file in HEAD, but\n the file in the merge-base.\n\n Or we can use \"-c\" in the first place, which gives us interesting\n and uninteresting parts, and then suppress the uninteresting ones.\n\n b. You can't stage part of a resolution. This is the \"adding a path\n collapses stages to #0\" that you mentioned. So either you need an\n index extension, or you need to make it all-or-nothing.\n\n> [discussion of how this could be done right]\n\nThat description makes sense to me, but is way overkill for my workflow.\nI think at its simplest, what I would like is to be shown the entire\n--cc diff, have it say \"do you want this and all of the cleanly merged\nbits added?\" and then either stage the whole thing or not.\n\nWhich really I could do with:\n\n for i in `git diff-files --name-only --diff-filter=U`; do\n git diff --cc $i\n echo 'OK?'\n read r\n test \"$r\" = y && git add $i\n done\n\nIt would just be a little nicer to have it integrated into the \"git add\n-p\" loop.\n\nEven though it is obviously a less featureful solution than what you\nproposed, I am tempted to implement it anyway because the current\nbehavior is so bad (it shows the diff but doesn't consider it a\nselectable hunk at all, so it just skips it, exiting immediately if\nthere are no other files).\n\nAnd then if somebody wants to spend time allowing partial resolution\nselection, it would be a nice improvement on top of that.\n\n-Peff\n"},{"id":"163176","messageId":"4D79460B.1000408@miseler.de","threadId":"26651","inReplyTo":"AANLkTinv-CQ4TKQu8T8o6K5aJ3ivdrScPN0shF=ma9Oz@mail.gmail.com","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Alexander Miseler","fromEmail":"alexander@miseler.de","sentAt":"2011-03-10T21:43:39Z","receivedAt":"2011-03-10T21:43:39Z","isPatch":false,"sender":{"key":"alexander@miseler.de","avatar":null},"body":"On 10.03.2011 18:31, Shawn Pearce wrote:\n> On Thu, Mar 10, 2011 at 08:30, Jeff King wrote:\n>>\n>>> 7. packfilev4.\n>>\n>> I suspect that is too complex for a SoC project. But you never know.\n> \n> It is. Nico is also probably working on it.\n> \n> My big concern with pack v4 right now is the on-disk format of\n> commits/trees is different from the current wire protocol. If a pack\n> v2 only client connected to a server using pack v4, the server would\n> have to spend a lot of time to inflate/deflate about 60% of the\n> objects in the repository (commits and trees). That is a lot of CPU\n> time. So even if a SoC-er finished the work, it probably wouldn't be\n> merged because of this penalty.\n\nI'm very interested in this. Can anyone please point me towards further information on the packfile format and proposed/in-progress changes?\n"},{"id":"163177","messageId":"20110310221809.GB15828@sigill.intra.peff.net","threadId":"26651","inReplyTo":"4D794531.40205@miseler.de","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-10T22:18:09Z","receivedAt":"2011-03-10T22:18:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 10, 2011 at 10:40:01PM +0100, Alexander Miseler wrote:\n\n> \"While git can handle arbitrary-sized binary content [...]\"\n> \n> This is very much not true. Git tries at many places to load the\n> complete file into memory and usually fails with \"out of memory\" if it\n> can't. With the 32bit msysGit client this places the upper file size\n> limit, from purely empirical observation, at 600-700 MByte.\n\nI think we are picking nits here. What I meant was two things:\n\n 1. The fundamental design of git does not prevent storing\n arbitrary-sized binary data.\n\n 2. How big a piece of data the current implementation can handle\n sanely is up to how much hardware you throw at it. On my 64-bit\n machine with 8G of RAM running Linux, I can easily work with 2\n gigabyte files. Some operations are slow, of course, but it works.\n\n I'm willing to accept that 32-bit msysgit has more trouble with\n a case like that.\n\nBut I think we are probably in agreement with what needs to be done to\nmake things better. Specifically, I am thinking of:\n\n 1. Streaming blobs wherever possible (e.g., add, filters, textconv).\n\n 2. Converting the diff code not to have in-memory files is probably\n going to be quite difficult. But most of these files don't have\n interesting diffs _anyway_. They're usually binary, and we don't\n generate binary diffs by default. So what we need to focus on is\n avoiding loading them when we can. Things like:\n\n a. Using caching textconv, and when we do run the textconv\n filter, streaming the blob to the filter.\n\n b. Avoid loading the whole file to check whether it is binary. We\n can already avoid this by marking it binary with\n gitattributes, but there is no reason git can't just load the\n first 4K or so to check for binary-ness, and get this\n optimization automatically. We can also consider caching\n binary-ness for large files so we don't have to look at them\n at all after the first time.\n\n c. Handle rename detection better. It may be a matter of saying\n \"this file is too big for detection\". But we may also be able\n to stream it through the spantree-hashing, and then possibly\n also cache the resultant data.\n\n 3. The above deal with memory problems. There is also a storage\n problem. If I have a 100G repo, right now I use at least 100G in\n the .git directory and 100G in the working tree. That's a problem\n for repos of that size. If I have a storage server on the LAN and\n want to accept the latency hit, it would be nice to keep the\n commits local and the giant blobs on the server. Especially coupled\n with the optimizations in (2), we can possibly avoid even having to\n touch those blobs at all in many cases, so the latency wouldn't be\n a big deal.\n\n 4. A related storage problem is that we put big files in packs, and\n the I/O on rewriting the pack becomes a problem. They would do\n better loose or in their own packs.\n\nAnd I'm sure there are more variations on those things. Part of the\nproject would be identifying the problem areas.\n\n> Even worse yet, commits consisting of smaller files but with a\n> combined size over the limit will also cause out-of-memories.\n\nThat generally should work OK. The diff and packing code tries to keep\nmemory usage reasonable, which generally equates to two times the\nlargest file. If you have a test case that shows problems, there may\nvery well be a bug.\n\n> Thus a main focus should be the memory problem, e.g. by using\n> stream-like file handling everywhere, since not working at all is\n> orders of magnitude worse than working slowly :)\n\nAgreed. I think they are sort of the same problem. Whether it works\nslowly or not at all is simply a matter of how much memory you have. ;)\n\n> Ironically git add is one of the few things that work with large\n> files, as mentioned above. Presumably the stream-oriented zlib\n> enforced/encouraged a steam-like handling here :) Slow as hell though\n> and of course it is usually not sensible to compress a 1.5 GByte file.\n\nI just tried \"git add\" on a 2G file of random bytes. It took about a\nminute or so to calculate the sha1 and compress it, but the memory usage\ndid jump to 2G. So we could obviously do better on the memory, and there\nis almost certainly no point in zlib compressing something that big. In\nmy case, it was obviously just random junk. But most files of that size\nare already going to have some kind of lossy compression, so we are just\nwasting CPU. You can always set core.compression, but I really just want\nit off for certain files.\n\n> I'm very willing to work on this topic. Though I'm not a student and\n> as a git code newbie I also don't have the skills for mentoring yet.\n\nIt's on my agenda, too. We'll see if a student steps up for the GSoC\nproject. But don't let that stop you if you want to take a look at it;\nI'm sure there is plenty of work to go around. :)\n\n-Peff\n"},{"id":"163184","messageId":"20110310224654.GA13702@book.hvoigt.net","threadId":"26651","inReplyTo":"20110309231604.GA3903@paksenarrion.iveqy.com","subject":"Re: Re: Re: Google Summer of Code 2011","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-03-10T22:46:55Z","receivedAt":"2011-03-10T22:46:55Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Thu, Mar 10, 2011 at 12:16:04AM +0100, Fredrik Gustafsson wrote:\n> On Wed, Mar 09, 2011 at 10:52:56PM +0100, Heiko Voigt wrote:\n> > Sounds promising. When I was talking about gui or submodules I did not\n> > think about gui *and* submodules. Do you have some concrete areas you\n> > would like to improve in mind?\n> \n> Many of the ideas I had was already mentioned in \n> https://github.com/jlehmann/git-submod-enhancements/wiki/\n> \n> The ones I feel is most important for me is:\n> * gitk: Add popup menu for submodules to see the detailed history of\n> changes\n> * Check before a push in the superproject that all submodules HEADs are\n> pushed\n> * Showing that a submodule has a HEAD not on any branch in “git status”\n> * Move the submodules git directories into the superproject’s .git so that\n> submodules can be created and deleted\n\nSounds like a good roadmap. From my viewpoint this includes enough work\nfor a summer. There are also enough small steps so even if only part of\nthis would be finished it would contain enough improvement for git.\nSince this is the first time I am offering to mentor I am not that\nfamilar how much work can be done during summer. What do others think?\n\n(added Jens to the CC)\n\n> With this said, I'm not familiar with the git codebase yet and does not\n> have any concrete solutions. For example, I don't understand why a\n> submodule doesn't get a default branch.\n\nThe familiarity with the code should not be a problem since the idea of\nthe Summer of Code is to allow more people to get involved into a\nproject.\n\nRegarding the default branch: The short answer is that git does not\nrecord any branchname but a specific revision using its SHA1. This is on\npurpose to make sure that you get exactly the code you had when you\ncreated the commit. But a default branch has been requested many times\nto make working easier. AFAIR it the consensus was that creating a\nbranch recursively by default would not be a good idea. But doing that on\nexplicit user request could be implemented as an option to ease users\nworkflow. So something like this could be discussed.\n\nCheers Heiko\n"},{"id":"163186","messageId":"7v8vwm37nk.fsf@alter.siamese.dyndns.org","threadId":"26651","inReplyTo":"20110310214206.GA15828@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-10T22:58:07Z","receivedAt":"2011-03-10T22:58:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Yes, I don't want to see cleanly merged parts. And \"--cc\" already does\n> what I want by not showing them.\n\nAre you sure about that?\n\nWhat \"--cc\" would show largely depends on what you have in your working\ntree. If your two branches fixed the same bug with very different\napproaches, you may resolve the conflict favouring what one side did while\ndiscarding everything the other side did. The file in your work tree might\nbe the same as \"git checkout --ours $that_path\" after a mergy operation.\n\"diff --cc\" won't show anything to you in such a case.\n\n> So my thinking was more along the lines of:\n>\n> 1. Get \"git diff HEAD file\" and store its hunks.\n>\n> 2. Get \"git diff --cc file\" and stores its hunks.\n>\n> 3. For each hunk in (1), if it does not have an analagous hunk in (2),\n> mark it for staging without asking the user.\n>\n> 4. For the remaining hunks in (1), show the user the analagous --cc\n> hunk from (2), and mark the hunk from (1) for staging if requested.\n>\n> 5. Create the final patch from the marked hunks, apply it to\n> HEAD:file, and put that in the index.\n\nActually, the largest problem I see in the above approach is _when_ you\nperform the first two steps, not the details of the later steps.\n\nThe user has complete freedom outside our control between the time the\nmergy operation leaves conflicts in the index and the time \"add -p\" is\ninvoked (except obviously the user cannot do any \"add\" to register the\nresolution for the whole file to the index, as there won't be any per-hunk\nresolution recording left to do by \"add -p\").\n\nAnd as I repeatedly said, grabbing \"--cc file\" must be done before the\nuser starts mucking with the file in the working tree for the approach to\nbe any useful.\n\n>> [discussion of how this could be done right]\n>\n> That description makes sense to me, but is way overkill for my workflow.\n\nObviously I don't think so. I'd rather consider what it does an absolute\nminimum (not the part that it stores in an index extension, but the part\nthat the reference it uses to compare against the working tree file is a\noriginal, mechanical merge result). By the way, I just relized that an\nindex extension similar to PRSF might be a way to properly give index log\nsimilar to the reflog you wanted to have the other day---every time you\n\"git add\", you record the previous state of the index entry there, so that\nit can be replayed in reverse.\n\n> Which really I could do with:\n>\n> for i in `git diff-files --name-only --diff-filter=U`; do\n> git diff --cc $i\n> echo 'OK?'\n\nAs you already know, I disagree the usefulness of this approach (see the\n\"Are you sure about that?\" discussion), hence I doubt the usefulness of\n\"have it integrated into the \"git add -p\" loop\".\n"},{"id":"163189","messageId":"20110310230958.GI15828@sigill.intra.peff.net","threadId":"26651","inReplyTo":"7v8vwm37nk.fsf@alter.siamese.dyndns.org","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-10T23:09:58Z","receivedAt":"2011-03-10T23:09:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 10, 2011 at 02:58:07PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Yes, I don't want to see cleanly merged parts. And \"--cc\" already does\n> > what I want by not showing them.\n> \n> Are you sure about that?\n\nWell, no. But my experience has been that its output is useful.\n\n> What \"--cc\" would show largely depends on what you have in your working\n> tree. If your two branches fixed the same bug with very different\n> approaches, you may resolve the conflict favouring what one side did while\n> discarding everything the other side did. The file in your work tree might\n> be the same as \"git checkout --ours $that_path\" after a mergy operation.\n> \"diff --cc\" won't show anything to you in such a case.\n\nActually, I think diff --cc is doing what I want there. If I take one\nside's content completely, then it is not interesting to me anymore.\nWhat I am really concerned about is doing a tricky content-level merge\nin my editor and then screwing up the result. Or _trying_ to take one\nside of the merge, and then screwing it up. So the \"diff --cc\" output\nafter I have mucked is useful for both those cases.\n\n> And as I repeatedly said, grabbing \"--cc file\" must be done before the\n> user starts mucking with the file in the working tree for the approach to\n> be any useful.\n\nI'm not sure I agree. The output after I have mucked is useful to me,\nand that is what this use-case is based on. So I think we are talking\nabout related but slightly different use cases.\n\n> > Which really I could do with:\n> >\n> > for i in `git diff-files --name-only --diff-filter=U`; do\n> > git diff --cc $i\n> > echo 'OK?'\n> \n> As you already know, I disagree the usefulness of this approach (see the\n> \"Are you sure about that?\" discussion), hence I doubt the usefulness of\n> \"have it integrated into the \"git add -p\" loop\".\n\nOK, let me put it this way. I am not volunteering to work on the\napproach you outlined. If you are, great. But if not, then what should\nbe done? The current behavior to show the diff and then exit is quite\nconfusing. At the very least, we should say something to the user about\nwhat happened (or even suppress the diff and just say \"these paths are\nunmerged, and we can't handle them in add -p\").\n\n-Peff\n"},{"id":"163213","messageId":"4D7A1325.1090003@miseler.de","threadId":"26651","inReplyTo":"20110309215841.GC4400@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Alexander Miseler","fromEmail":"alexander@miseler.de","sentAt":"2011-03-11T12:18:45Z","receivedAt":"2011-03-11T12:18:45Z","isPatch":false,"sender":{"key":"alexander@miseler.de","avatar":null},"body":"On 09.03.2011 22:58, Jeff King wrote:\n> If you have any ideas, please add them to the page! Whether you are\n> available to mentor the project, or simply think it would make a good\n> project and want to inspire others to mentor it, it's appropriate to go\n> there.\n\nAdded two new ideas:\nPort Git to Android\nResumable clone\n\nI'm new to the Git code and therefore don't necessarily have an idea what I'm talking about. Please feel free to change, \ncorrect, mutilate and massacre this ideas. This are just two things that I would like to see, but don't want to work on \nmyself since I have BIGGER fishes to fry ^_^\n"},{"id":"163215","messageId":"AANLkTi=RVW8osJaSi1mDhNuOrFksHhAjtPdfdeXQoFeC@mail.gmail.com","threadId":"26651","inReplyTo":"20110309215841.GC4400@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-03-11T12:43:39Z","receivedAt":"2011-03-11T12:43:39Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Mar 9, 2011 at 22:58, Jeff King wrote:\n> If you have any ideas, please add them to the page!\n\nHere's a simple one:\n\nCurrently we have a global UI color setting, but pretty much only\ngit-status/log/etc use it.\n\nChange git-bisect, git-am etc. to also support color output. It would\nbe a easy but big UI win.\n"},{"id":"163216","messageId":"20110311125259.GA777@LK-Perkele-VI.localdomain","threadId":"26651","inReplyTo":"4D7A1325.1090003@miseler.de","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2011-03-11T12:52:59Z","receivedAt":"2011-03-11T12:52:59Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Fri, Mar 11, 2011 at 01:18:45PM +0100, Alexander Miseler wrote:\n> On 09.03.2011 22:58, Jeff King wrote:\n> >If you have any ideas, please add them to the page! Whether you are\n> >available to mentor the project, or simply think it would make a good\n> >project and want to inspire others to mentor it, it's appropriate to go\n> >there.\n> \n\n> Resumable clone\n\nThis is very very hard. Not so much to implement but to design the way it\ncan be done without assuming things (like object sort orders) that aren't\nstable.\n\n-Ilari\n"},{"id":"163218","messageId":"201103111428.05627.trast@student.ethz.ch","threadId":"26651","inReplyTo":"m339mu7u6n.fsf@localhost.localdomain","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-03-11T13:28:05Z","receivedAt":"2011-03-11T13:28:05Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jakub Narebski wrote:\n> Jonathan Nieder writes:\n> \n> > 4. filter-branch killer: using fast-import's new features to implement\n> > common filter-branch operations (--subdirectory-filter,\n> > --prune-empty, obliterating certain files) faster.\n> \n> How it would be different from existing reposurgeon tool by ESR\n> (cross-VC thanks to using fast-import format), or git_fast_filter by\n> Elijah Newren (more of a library than a ready tool)?\n\nGit integration? I haven't looked at these tools for long enough to\nsay how much they fit the ticket and how fast they are, so for me it's\nhard to say how much work it would be.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"163219","messageId":"201103111431.04066.trast@student.ethz.ch","threadId":"26651","inReplyTo":"20110310184653.GA17832@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-03-11T13:31:03Z","receivedAt":"2011-03-11T13:31:03Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King wrote:\n> On Thu, Mar 10, 2011 at 06:15:23PM +0100, Thomas Rast wrote:\n> \n> > * Clean up add -p\n> \n> One more wishlist item for this. I use \"add -p\" for almost all of my\n> adds these days, because I like the final review check. So after a\n> conflicted merge, I find myself doing \"add -p\" to stage my resolution.\n> The current behavior is that it shows the --cc diff and exits. It would\n> be cool to handle staging the resolution, which would involve converting\n> the combined diff into something that can be applied.\n\nGood idea, thanks.\n\nI put this (with your idea) and the word-merge thing on the wiki.\nI'll let Jonathan decide what to do about the fast-import stream\nfiltering.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"163220","messageId":"AANLkTin30fZURU-PxddSai5Qzfqjtwej=maGssyr2b7W@mail.gmail.com","threadId":"26651","inReplyTo":"20110311125259.GA777@LK-Perkele-VI.localdomain","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-11T13:48:14Z","receivedAt":"2011-03-11T13:48:14Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Mar 11, 2011 at 7:52 PM, Ilari Liusvaara\n wrote:\n> On Fri, Mar 11, 2011 at 01:18:45PM +0100, Alexander Miseler wrote:\n>> On 09.03.2011 22:58, Jeff King wrote:\n>> >If you have any ideas, please add them to the page! Whether you are\n>> >available to mentor the project, or simply think it would make a good\n>> >project and want to inspire others to mentor it, it's appropriate to go\n>> >there.\n>>\n>\n>> Resumable clone\n>\n> This is very very hard. Not so much to implement but to design the way it\n> can be done without assuming things (like object sort orders) that aren't\n> stable.\n\nYes it's hard. I have some experimental thing that nearly works [1],\nalthough whether it is an acceptable approach is to be seen. If\nanyone's interested, I'll post it some time\n\nA simpler way to restartable clone is to facilitate bundles (Nicolas'\nidea). Some glue is needed to teach git-fetch/git-daemon to use the\nbundles, and git-push to automatically create bundles periodically (or\na new command that can be run from cron). I think this way fit in GSoC\nscope better.\n\n[1] The idea of my work above was mentioned elsewhere, history is cut\ndown by path. Each file/dir's history a very long chain of deltas. We\ncan stream deltas (in parallel if needed) over the wire, resuming\nwhere the chain stops last time.\n\nThere are many problems. One is that a deep chain can make git run out\nof stack, so chains have to be broken down before storing (not done).\nAnother one is that not many deltas can be reused, so it will consume\nmore power than normal clone. But once you clone this way, the cloned\nrepo have lots of delta suitable for another clone (but probably not\nfor anything else).\n-- \nDuy\n"},{"id":"163221","messageId":"4D7A2D47.9010101@miseler.de","threadId":"26651","inReplyTo":"AANLkTin30fZURU-PxddSai5Qzfqjtwej=maGssyr2b7W@mail.gmail.com","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Alexander Miseler","fromEmail":"alexander@miseler.de","sentAt":"2011-03-11T14:10:15Z","receivedAt":"2011-03-11T14:10:15Z","isPatch":false,"sender":{"key":"alexander@miseler.de","avatar":null},"body":"On 11.03.2011 14:48, Nguyen Thai Ngoc Duy wrote:\n> On Fri, Mar 11, 2011 at 7:52 PM, Ilari Liusvaara\n> wrote:\n>> On Fri, Mar 11, 2011 at 01:18:45PM +0100, Alexander Miseler wrote:\n>>> Resumable clone\n>>\n>> This is very very hard. Not so much to implement but to design the way it\n>> can be done without assuming things (like object sort orders) that aren't\n>> stable.\n>\n> Yes it's hard. I have some experimental thing that nearly works [1],\n> although whether it is an acceptable approach is to be seen. If\n> anyone's interested, I'll post it some time\n>\n> A simpler way to restartable clone is to facilitate bundles (Nicolas'\n> idea). Some glue is needed to teach git-fetch/git-daemon to use the\n> bundles, and git-push to automatically create bundles periodically (or\n> a new command that can be run from cron). I think this way fit in GSoC\n> scope better.\n>\n> [1] The idea of my work above was mentioned elsewhere, history is cut\n> down by path. Each file/dir's history a very long chain of deltas. We\n> can stream deltas (in parallel if needed) over the wire, resuming\n> where the chain stops last time.\n>\n> There are many problems. One is that a deep chain can make git run out\n> of stack, so chains have to be broken down before storing (not done).\n> Another one is that not many deltas can be reused, so it will consume\n> more power than normal clone. But once you clone this way, the cloned\n> repo have lots of delta suitable for another clone (but probably not\n> for anything else).\n\n\nThis may all be aiming to short. IMHO the best solution would be some generic way for the client to specify exactly what \nit wants to get and to get just that. This would lay the groundwork for:\n- lazy clones\n- sparse clones\n- resumable cloning\n- resumable fetching\nand probably quite a few other nifty tricks.\n\nI guess that would be far beyond the scope of a SoC project though.\n"},{"id":"163222","messageId":"4D7A2EFC.3020505@miseler.de","threadId":"26651","inReplyTo":"20110310221809.GB15828@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Alexander Miseler","fromEmail":"alexander@miseler.de","sentAt":"2011-03-11T14:17:32Z","receivedAt":"2011-03-11T14:17:32Z","isPatch":false,"sender":{"key":"alexander@miseler.de","avatar":null},"body":"On 10.03.2011 23:18, Jeff King wrote:\n> 1. The fundamental design of git does not prevent storing\n> arbitrary-sized binary data.\n\nagreed\n\n\n> But I think we are probably in agreement with what needs to be done to\n> make things better. Specifically, I am thinking of:\n\nagreed\n\n\n>> Even worse yet, commits consisting of smaller files but with a\n>> combined size over the limit will also cause out-of-memories.\n>\n> That generally should work OK. The diff and packing code tries to keep\n> memory usage reasonable, which generally equates to two times the\n> largest file. If you have a test case that shows problems, there may\n> very well be a bug.\n\nI will look into it.\n\n\n> But don't let that stop you if you want to take a look at it;\n> I'm sure there is plenty of work to go around. :)\n\nCertainly ^_^\n"},{"id":"163223","messageId":"229797324-1299853442-cardhu_decombobulator_blackberry.rim.net-1488450281-@bda570.bisx.prod.on.blackberry","threadId":"26651","inReplyTo":"AANLkTi=RVW8osJaSi1mDhNuOrFksHhAjtPdfdeXQoFeC@mail.gmail.com","subject":"Re: Summer of Code project ideas due this Friday","fromName":"","fromEmail":"code.sculptor@gmail.com","sentAt":"2011-03-11T14:24:13Z","receivedAt":"2011-03-11T14:24:13Z","isPatch":false,"sender":{"key":"code.sculptor@gmail.com","avatar":null},"body":"Great idea!\nSent from my BlackBerry device on the Rogers Wireless Network\n\n-----Original Message-----\nFrom: Ævar Arnfjörð Bjarmason \nSender: git-owner@vger.kernel.org\nDate: Fri, 11 Mar 2011 13:43:39 \nTo: Jeff King\nCc: Shawn Pearce; Ramkumar Ramachandra; Jonathan Nieder; Jens Lehmann; Christian Couder; Thomas Rast; git\nSubject: Re: Summer of Code project ideas due this Friday\n\nOn Wed, Mar 9, 2011 at 22:58, Jeff King wrote:\n> If you have any ideas, please add them to the page!\n\nHere's a simple one:\n\nCurrently we have a global UI color setting, but pretty much only\ngit-status/log/etc use it.\n\nChange git-bisect, git-am etc. to also support color output. It would\nbe a easy but big UI win.\n--\nTo unsubscribe from this list: send the line \"unsubscribe git\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"163224","messageId":"AANLkTinKnfiE9zQwYxfCX8VhRfgJhQopDbqBA+oQLL0w@mail.gmail.com","threadId":"26651","inReplyTo":"4D7A2D47.9010101@miseler.de","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-11T14:27:50Z","receivedAt":"2011-03-11T14:27:50Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Mar 11, 2011 at 9:10 PM, Alexander Miseler wrote:\n> This may all be aiming to short. IMHO the best solution would be some\n> generic way for the client to specify exactly what it wants to get and to\n> get just that.\n\nBut how do you define \"what it wants to get\"? Pros and cons are\ndifferent and depend on that defintion.\n\nGit's way of saying now is \"I have these commits, give me these\nbranches (cutting at certain depth)\". A near future extension would be\n\"I have these commits _restricted to these paths only_, give me...\".\nIf it's broken half way, start again.\n\nThe bundle way is basically Git's way except that the remote side says\n\"I've got this bundle, fetch it here, then you can ask us again for\nthe rest in a normal way\".\n\nmirrorsync (aka gittorrent) says \"I have this commit, give me objects\nso that I can have this commit\", which leaves the (probably) huge\ninitial commit out of view.\n\nMy way is \"give me a chain of deltas starting from this SHA-1\". A big\nblob can be considered as a history of smaller pieces.\n\nThe last way of saying is just \"give me this object\", which would be a\nbig waste of bandwidth.\n\nYour move :)\n-- \nDuy\n"},{"id":"163250","messageId":"4D7AA545.4050006@vilain.net","threadId":"26651","inReplyTo":"AANLkTinKnfiE9zQwYxfCX8VhRfgJhQopDbqBA+oQLL0w@mail.gmail.com","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2011-03-11T22:42:13Z","receivedAt":"2011-03-11T22:42:13Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On 12/03/11 03:27, Nguyen Thai Ngoc Duy wrote:\n> On Fri, Mar 11, 2011 at 9:10 PM, Alexander Miseler wrote:\n>> This may all be aiming to short. IMHO the best solution would be some\n>> generic way for the client to specify exactly what it wants to get and to\n>> get just that.\n> But how do you define \"what it wants to get\"? Pros and cons are\n> different and depend on that defintion.\n>\n> Git's way of saying now is \"I have these commits, give me these\n> branches (cutting at certain depth)\". A near future extension would be\n> \"I have these commits _restricted to these paths only_, give me...\".\n> If it's broken half way, start again.\n>\n> The bundle way is basically Git's way except that the remote side says\n> \"I've got this bundle, fetch it here, then you can ask us again for\n> the rest in a normal way\".\n>\n> mirrorsync (aka gittorrent) says \"I have this commit, give me objects\n> so that I can have this commit\", which leaves the (probably) huge\n> initial commit out of view.\n>\n> My way is \"give me a chain of deltas starting from this SHA-1\". A big\n> blob can be considered as a history of smaller pieces.\n>\n> The last way of saying is just \"give me this object\", which would be a\n> big waste of bandwidth.\n>\n> Your move :)\n\nJust FWIW, I recently produced some diagrams and demonstrated the\nresumable clone algorithm; speed is currently very limited by the\nimplementation at 15 minutes to slice up git.git; but I'm playing with\nlibgit2 to see if I can make a more optimal version.\n\nSee http://vilain.net/comp/git/gittorrent/commit_reel.html\n\nSam\n"},{"id":"163255","messageId":"20110312002017.GA16081@elie","threadId":"26651","inReplyTo":"m339mu7u6n.fsf@localhost.localdomain","subject":"History surgery with fast-import (Re: Summer of Code project ideas due this Friday)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-03-12T00:20:17Z","receivedAt":"2011-03-12T00:20:17Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jakub Narebski wrote:\n> Jonathan Nieder writes:\n\n>> 4. filter-branch killer: using fast-import's new features to implement\n>> common filter-branch operations (--subdirectory-filter,\n>> --prune-empty, obliterating certain files) faster.\n>\n> How it would be different from existing reposurgeon tool by ESR\n> (cross-VC thanks to using fast-import format), or git_fast_filter by\n> Elijah Newren (more of a library than a ready tool)?\n\nGood question.\n\n. reposurgeon loads the whole history into a convenient format,\n manipulates it, then dumps it as a separate step. So it is even more\n flexible than filter-branch, but with a large history and especially\n on a small machine it can be slower.\n\n. git_fast_filter is what Thomas mentioned --- a filter to go between\n fast-export and fast-import.\n\nBoth involve unpacking all trees. Which is not a huge expense, mind\nyou, but there is room to go faster.\n\nWhat I was suggesting is instead a tool that relies on fast-import to\ndo the heavy lifting. So, for example, when you ask to delete\npath/to/remove.txt from all commits, it would write:\n\n commit refs/heads/master\n mark :172\n author A U Thor ...\n committer ...\n data ...\n from ...\n merge ...\n M 040000 [old tree name for that commit] \"\"\n D path/to/remove.txt\n\n commit refs/heads/mater\n mark :173\n ...\n\nThe idea is inspired by\nhttp://thread.gmane.org/gmane.comp.version-control.git/158375\nI am interested in it because I imagine something like this could be\nuseful for splitting out branches from a naive import of an svn repo\n(and similar surgeries).\n"},{"id":"163268","messageId":"4D7BCDBB.7080604@miseler.de","threadId":"26651","inReplyTo":"4D7A2EFC.3020505@miseler.de","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Alexander Miseler","fromEmail":"alexander@miseler.de","sentAt":"2011-03-12T19:47:07Z","receivedAt":"2011-03-12T19:47:07Z","isPatch":false,"sender":{"key":"alexander@miseler.de","avatar":null},"body":">>> Even worse yet, commits consisting of smaller files but with a\n>>> combined size over the limit will also cause out-of-memories.\n>>\n>> That generally should work OK. The diff and packing code tries to keep\n>> memory usage reasonable, which generally equates to two times the\n>> largest file. If you have a test case that shows problems, there may\n>> very well be a bug.\n> \n> I will look into it.\n\nI failed to create an artificial test case for this (thus probably misunderstanding the exact circumstances leading to this). I will investigate it when I get a real life test case again.\n"},{"id":"163270","messageId":"4D7BE877.2000607@miseler.de","threadId":"26651","inReplyTo":"AANLkTinKnfiE9zQwYxfCX8VhRfgJhQopDbqBA+oQLL0w@mail.gmail.com","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Alexander Miseler","fromEmail":"alexander@miseler.de","sentAt":"2011-03-12T21:41:11Z","receivedAt":"2011-03-12T21:41:11Z","isPatch":false,"sender":{"key":"alexander@miseler.de","avatar":null},"body":"> Your move :)\n\nHeh, I'm still pretty hampered by having no clue ^_^\n\n\n> My way is \"give me a chain of deltas starting from this SHA-1\". A big\n> blob can be considered as a history of smaller pieces.\n\nI originally missed the fact that it is completely irrelevant where in the chain the reference point is and that you can go easily from any arbitrary point in the chain to any other arbitrary point in the same chain. This makes it a lot more flexible than I thought. But to support more than just resumable cloning You would still need a more powerful way to negotiate \"I have this; I want that\" between client and server.\n\nMy point was mostly that lazy clone, sparse clone and resumable clone are closely related and should ideally be solved in one go. You currently seem to aim at only one of them, which is a shame.\nFor lazy clone the client would start with all blobs referenced by HEAD (and possibly other branches) and then it would walk backwards through the delta chains if/as far/whenever it wants. Though it would also need to detect when it needs to start reading new delta chains as it walks backwards through history. Sparse clone would use the same mechanism and just restrict it to certain paths.\n"},{"id":"163290","messageId":"20110313170815.GB19763@kytes","threadId":"26651","inReplyTo":"20110310001017.GA24169@elie","subject":"Re: Summer of Code project ideas due this Friday","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-03-13T17:08:19Z","receivedAt":"2011-03-13T17:08:19Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Jonathan,\n\nJonathan Nieder writes:\n> 3. Remote helpers: bidi git remote-svn (or one-way remote-hg, or\n> remote-cvs, or ...).\n\nI wrote a small introduction and created an entry for git-remote-svn\nin the wiki [1]. Two minor concerns:\n1. The student will have to work very closely with us, and pick up a\n lot of scattered WIP patches. I hope he doesn't get confused\n between what's merged and what's in-progress.\n2. The project isn't as de-coupled as we'd ideally like. The student\n has to learn about the new fast-import features, and the\n information contained in an SVN replay dumpstream before diving in.\n\nOther than these, I think most of the pending work is in the mapper.\n\n> 4. filter-branch killer: using fast-import's new features to implement\n> common filter-branch operations (--subdirectory-filter,\n> --prune-empty, obliterating certain files) faster.\n\nThis is an interesting project that I'd also thought about: it might\nget tangled up along with the Sequencer project though. Should we put\nup this project on the wiki nevertheless?\n\np.s- Sorry about the late reply; I wasn't in station.\n\n[1] SoC2011Ideas#Welcome and SoC2011Ideas#Remote_helper_for_Subversion\n\n-- Ram\n"},{"id":"163602","messageId":"m37hbx5ncw.fsf_-_@localhost.localdomain","threadId":"26651","inReplyTo":"20110309215841.GC4400@sigill.intra.peff.net","subject":"Re: Summer of Code project ideas","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-03-17T23:40:44Z","receivedAt":"2011-03-17T23:40:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King writes:\n\n> https://git.wiki.kernel.org/index.php/SoC2011Ideas\n> \n> If you have any ideas, please add them to the page!\n\nA few project ideas I am not sure if they are feasible for GSoC:\n\n* merging-in support for caching in gitweb, and benchmarking/profiling\n gitweb in high load situation\n\n J.H., you would probably want gitweb [output] caching to be merged-in\n sooner that the end of Google Summer of Code 2011, isn't it?\n\n* embedding graphical diff and graphical merge tool in git-gui, e.g. as\n \"git gui diff\". I think that we can use xxdiff; the license is \n compatibile.\n\n Pat and Shawn, is it something worth doing? Does it look like a good\n project for GSoC2011, or is it too small of a project for this? Would\n we be able to find mentor for this idea?\n\n* splitting gitk, common library (Tcl/Tk bindings) for gitk and git-gui\n\n Pat and Paul, do you think it is right scope, or is it too large project\n to put as an GSoC idea?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"164086","messageId":"20110322203157.GA21163@book.hvoigt.net","threadId":"26651","inReplyTo":"m37hbx5ncw.fsf_-_@localhost.localdomain","subject":"Re: Re: Summer of Code project ideas","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-03-22T20:31:57Z","receivedAt":"2011-03-22T20:31:57Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Thu, Mar 17, 2011 at 04:40:44PM -0700, Jakub Narebski wrote:\n> * embedding graphical diff and graphical merge tool in git-gui, e.g. as\n> \"git gui diff\". I think that we can use xxdiff; the license is \n> compatibile.\n> \n> Pat and Shawn, is it something worth doing? Does it look like a good\n> project for GSoC2011, or is it too small of a project for this? Would\n> we be able to find mentor for this idea?\n> \n> * splitting gitk, common library (Tcl/Tk bindings) for gitk and git-gui\n> \n> Pat and Paul, do you think it is right scope, or is it too large project\n> to put as an GSoC idea?\n\nI would be interested in mentoring those projects. I do not know whether\nwe can reach consensus how to split up things. The last time we\ndiscussed a possible approach[1] to share code between gitk and git gui\nwe did not reach one.\n\nCheers Heiko\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/166663/focus=166695\n"},{"id":"164098","messageId":"4D8928F2.2010604@eaglescrag.net","threadId":"26651","inReplyTo":"m37hbx5ncw.fsf_-_@localhost.localdomain","subject":"Re: Summer of Code project ideas","fromName":"J.H.","fromEmail":"warthog9@eaglescrag.net","sentAt":"2011-03-22T22:55:46Z","receivedAt":"2011-03-22T22:55:46Z","isPatch":false,"sender":{"key":"warthog9@kernel.org","avatar":"https://avatars.githubusercontent.com/u/2334704?v=4"},"body":"On 03/17/2011 04:40 PM, Jakub Narebski wrote:\n> Jeff King writes:\n> \n>> https://git.wiki.kernel.org/index.php/SoC2011Ideas\n>>\n>> If you have any ideas, please add them to the page!\n> \n> A few project ideas I am not sure if they are feasible for GSoC:\n> \n> * merging-in support for caching in gitweb, and benchmarking/profiling\n> gitweb in high load situation\n> \n> J.H., you would probably want gitweb [output] caching to be merged-in\n> sooner that the end of Google Summer of Code 2011, isn't it?\n\nI think the work needed to get gitweb-caching actually merged upstream\nis going to be a slight bit messier than I'm willing to put a student\nthrough, and couple that with the fact I'm going to be herding 2 or 3\nstudents for kernel.org as already, I won't have enough time to try and\nmentor a student through that quagmire.\n\nShould a student be interested in the graphing stuff for gitweb, I'm\nhappy to make commentary and review things as they come, but that's at\nbest a co-mentor from me.\n"},{"id":"164269","messageId":"878vw4c8c5.fsf@fox.patthoyts.tk","threadId":"26651","inReplyTo":"m37hbx5ncw.fsf_-_@localhost.localdomain","subject":"Re: Summer of Code project ideas","fromName":"Pat Thoyts","fromEmail":"patthoyts@users.sourceforge.net","sentAt":"2011-03-25T01:11:38Z","receivedAt":"2011-03-25T01:11:38Z","isPatch":false,"sender":{"key":"patthoyts@users.sourceforge.net","avatar":"https://avatars.githubusercontent.com/u/30739?v=4"},"body":"Jakub Narebski writes:\n\n>Jeff King writes:\n>\n>> https://git.wiki.kernel.org/index.php/SoC2011Ideas\n>> \n>> If you have any ideas, please add them to the page!\n>\n>A few project ideas I am not sure if they are feasible for GSoC:\n>\n>* merging-in support for caching in gitweb, and benchmarking/profiling\n> gitweb in high load situation\n>\n> J.H., you would probably want gitweb [output] caching to be merged-in\n> sooner that the end of Google Summer of Code 2011, isn't it?\n>\n>* embedding graphical diff and graphical merge tool in git-gui, e.g. as\n> \"git gui diff\". I think that we can use xxdiff; the license is \n> compatibile.\n>\n> Pat and Shawn, is it something worth doing? Does it look like a good\n> project for GSoC2011, or is it too small of a project for this? Would\n> we be able to find mentor for this idea?\n\nThere is also tkdiff for stealing from. I'm not sure about the worth -\nthere are lots of free merge tools around. But if someone wants to do\nthat then fine.\n\n>* splitting gitk, common library (Tcl/Tk bindings) for gitk and git-gui\n>\n> Pat and Paul, do you think it is right scope, or is it too large project\n> to put as an GSoC idea?\n\nIt shouldn't be too large. You are likely looking at doing Git.pm as a\nTcl package (without looking in much detail). Testing that gitk and\ngit-gui didn't get broken will probably be tedious. So adding some test\nsuite to each could help. The Tcl test package is quite capable of being\nused to test Tk apps provided some tests get written.\n\n-- \nPat Thoyts http://www.patthoyts.tk/\nPGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD\n"},{"id":"164295","messageId":"201103251402.16280.jnareb@gmail.com","threadId":"26651","inReplyTo":"878vw4c8c5.fsf@fox.patthoyts.tk","subject":"Re: Summer of Code project ideas","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-03-25T13:02:14Z","receivedAt":"2011-03-25T13:02:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 25 Mar 2011, Pat Thoyts wrote:\n> Jakub Narebski writes:\n\n> > A few project ideas I am not sure if they are feasible for GSoC:\n\n> > * embedding graphical diff and graphical merge tool in git-gui, e.g. as\n> > \"git gui diff\". I think that we can use xxdiff; the license is \n> > compatibile.\n> >\n> > Pat and Shawn, is it something worth doing? Does it look like a good\n> > project for GSoC2011, or is it too small of a project for this? Would\n> > we be able to find mentor for this idea?\n> \n> There is also tkdiff for stealing from. I'm not sure about the worth -\n> there are lots of free merge tools around. But if someone wants to do\n> that then fine.\n\nI meant TkDiff, not xxdiff here; I'm sorry for the mistake.\n\nTkDiff has the advantage that is already written in Tcl/Tk, so we can\nborrow code (like e.g. \"refining\" diff), not only algorithms.\n\n> > * splitting gitk, common library (Tcl/Tk bindings) for gitk and git-gui\n> >\n> > Pat and Paul, do you think it is right scope, or is it too large project\n> > to put as an GSoC idea?\n> \n> It shouldn't be too large. You are likely looking at doing Git.pm as a\n> Tcl package (without looking in much detail). Testing that gitk and\n> git-gui didn't get broken will probably be tedious. So adding some test\n> suite to each could help. The Tcl test package is quite capable of being\n> used to test Tk apps provided some tests get written.\n\nI thought that would be mainly re-using library part of git-gui in gitk;\ntests are decidely a good idea, though I don't know if there are ready\ntools to do tests for programs written in Tcl/Tk , and for testing UI.\n\n-- \nJakub Narebski\nPoland\n"}]}