{"thread":{"id":"41380","subject":"GSoC 2016: applications open, deadline = Fri, 19/2","startedAt":"2016-02-10T09:31:26Z","lastAt":"2016-03-09T19:34:15Z","messageCount":67,"participants":["Matthieu Moy","Johannes Schindelin","Stefan Beller","Christian Couder","Lars Schneider","Jeff King","Duy Nguyen","Nguyễn Thái Ngọc Duy","Thomas Gummerer","Junio C Hamano","Carlos Martín Nieto"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"277855","messageId":"vpqoabox66p.fsf@anie.imag.fr","threadId":"41380","inReplyTo":null,"subject":"GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-10T09:31:26Z","receivedAt":"2016-02-10T09:31:26Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Hi,\n\nThe GSoC (Google Summer of Code) application for mentoring organizations\nis now open. The deadline is Friday, February 19 at 19:00 UTC. That is:\nvery soon. New website here: https://summerofcode.withgoogle.com/. More\ninfo about Git's previous GSoC iterations there:\nhttp://git.github.io/SoC-2015-Microprojects/,\nhttp://git.github.io/SoC-2015-Org-Application/.\n\nI haven't been watching the list very closely the last few weeks, but I\ndidn't see a discussion on whether we shall participate this year, other\nthan \"Starting on a microproject for GSoC\"\n(http://thread.gmane.org/gmane.comp.version-control.git/284958).\n\nI think participating is a good thing, but it needs mentors, ie. people\nand time. On my side, I'd be happy to give a hand to GSoC, but\nunfortunately, I won't have time to properly mentor a student. I can be\nco-admin, and can help someone to mentor, but only if this someone\nagrees to do most of the work. Yes, I do realize that this sounds like\n\"we should do it, but someone else should do the work\" ;-).\n\nSo, the first question is: are there volunteers to be GSoC mentors this\nyear? For those who never did it: mentoring means giving advices to the\nstudent (partly done during the \"microproject\" phase in our\norganization), participating actively in reviews (possibly doing some\nfirst review iterations off-list to avoid overloading the list). On\noverall, the goal is to make sure that some useful code is merged before\nthe end. It's a very enjoyable experience, it can be done with\nreasonable knowledge of Git's codebase and community (no need to be an\nold-timer), but it needs time to be done properly (expect to get ~10\niterations of each patch series, and spend hour(s) on each). And you get\na nice tee-shirt to show off with your geek friends.\n\nIf we have enough potential mentors, then the next questions are: who's\nthe admin? Work on the application itself, and on the list of ideas.\n\nCheers,\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"277857","messageId":"alpine.DEB.2.20.1602101208550.2964@virtualbox","threadId":"41380","inReplyTo":"vpqoabox66p.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-02-10T11:09:48Z","receivedAt":"2016-02-10T11:09:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Matthieu,\n\nOn Wed, 10 Feb 2016, Matthieu Moy wrote:\n\n> I think participating is a good thing, but it needs mentors, ie. people\n> and time.\n\nI am available for mentoring. Stefan, it was really fun to co-mentor with\nyou, would you be willing to repeat the exercise?\n\nCiao,\nDscho\n"},{"id":"277879","messageId":"CAGZ79kbSrUv4d5wZgeGh7BY1KCr35YRZ+uWb-ADoHmNS86WHTQ@mail.gmail.com","threadId":"41380","inReplyTo":"alpine.DEB.2.20.1602101208550.2964@virtualbox","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-02-10T17:44:07Z","receivedAt":"2016-02-10T17:44:07Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Feb 10, 2016 at 3:09 AM, Johannes Schindelin\n wrote:\n> Hi Matthieu,\n>\n> On Wed, 10 Feb 2016, Matthieu Moy wrote:\n>\n>> I think participating is a good thing, but it needs mentors, ie. people\n>> and time.\n\nI am people and I have time! ;)\n\n>\n> I am available for mentoring. Stefan, it was really fun to co-mentor with\n> you, would you be willing to repeat the exercise?\n\nSure thing.\n\n>\n> Ciao,\n> Dscho\n"},{"id":"277910","messageId":"CAP8UFD0UxB6Z1UU=4Bkz0Yt2KE+AkrttQeTx2oY9v9O78f9qow@mail.gmail.com","threadId":"41380","inReplyTo":"vpqoabox66p.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2016-02-11T08:36:40Z","receivedAt":"2016-02-11T08:36:40Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Wed, Feb 10, 2016 at 10:31 AM, Matthieu Moy\n wrote:\n>\n> So, the first question is: are there volunteers to be GSoC mentors this\n> year?\n\nI can co-mentor this year too, with you or someone else.\nWith you I think it will work out even if you have less time than last year.\n\nBest,\nChristian.\n"},{"id":"277998","messageId":"vpqd1s2e74l.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"CAP8UFD0UxB6Z1UU=4Bkz0Yt2KE+AkrttQeTx2oY9v9O78f9qow@mail.gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-12T07:10:34Z","receivedAt":"2016-02-12T07:10:34Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Christian Couder writes:\n\n> Hi,\n>\n> On Wed, Feb 10, 2016 at 10:31 AM, Matthieu Moy\n> wrote:\n>>\n>> So, the first question is: are there volunteers to be GSoC mentors this\n>> year?\n>\n> I can co-mentor this year too, with you or someone else.\n> With you I think it will work out even if you have less time than last year.\n\nSo, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not\nmuch, but it starts looking like last year ... ;-).\n\nPeff, would you be willing to co-admin with me (that would be cool, you\nare the one with most experience here and you know the SFC stuff for\npayment)? Are there any other co-admin volunteer?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"277999","messageId":"ED514A90-08AB-4EBC-BA17-ABAA06FE64FE@gmail.com","threadId":"41380","inReplyTo":"vpqd1s2e74l.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-02-12T08:29:28Z","receivedAt":"2016-02-12T08:29:28Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 12 Feb 2016, at 08:10, Matthieu Moy wrote:\n\n> Christian Couder writes:\n> \n>> Hi,\n>> \n>> On Wed, Feb 10, 2016 at 10:31 AM, Matthieu Moy\n>> wrote:\n>>> \n>>> So, the first question is: are there volunteers to be GSoC mentors this\n>>> year?\n>> \n>> I can co-mentor this year too, with you or someone else.\n>> With you I think it will work out even if you have less time than last year.\n> \n> So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not\n> much, but it starts looking like last year ... ;-).\n> \n> Peff, would you be willing to co-admin with me (that would be cool, you\n> are the one with most experience here and you know the SFC stuff for\n> payment)? Are there any other co-admin volunteer?\n\nI don't know what level of Git development knowledge and what amount of time\nis necessary but I would be available as junior co-mentor :-)\n\nCheers,\nLars"},{"id":"278000","messageId":"vpqio1ucmyv.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"ED514A90-08AB-4EBC-BA17-ABAA06FE64FE@gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-12T09:11:20Z","receivedAt":"2016-02-12T09:11:20Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Lars Schneider writes:\n\n> I don't know what level of Git development knowledge and what amount of time\n> is necessary but I would be available as junior co-mentor :-)\n\nAFAICT, you don't have much experience with Git's codebase itself (if I\ndon't count git-p4 as \"Git itself\"), but you've already been involved in\ntypical reviewing cycles (just the discussions on Travis-CI were a good\nexample), and that is something at least as important as knowing the\ncodebase well. It's up to you to decide whether you feel experienced\nenough, but I think you are welcome as a co-mentor!\n\nAs a mentor, to me, the most important things are:\n\n* Give advice on how to interact with the Git community. Students can be\n shy, and then repeating \"you should post more to the mailing-list\" can\n be useful. They sometimes make mistakes, and explaining off-list\n \"there's nothing wrong with what you did, but the custom here is\n to ...\" can help.\n\n* Give advice on how to get useful code merged. My usual advice is:\n \"don't be too ambitious\", which translates to \"git this part done,\n reviewed and possibly merged, you'll work on the bells and whistles\n later\".\n\n* Avoid overloading the list with reviews. Getting your own GSoC\n tee-shirt and letting the list do the work is unfair ;-). Off-list\n reviews are good to eliminate straightforwards issues, and then\n mentors should actively participate to the on-list review. That is\n probably what takes most time.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278005","messageId":"20160212130446.GB10858@sigill.intra.peff.net","threadId":"41380","inReplyTo":"vpqd1s2e74l.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-12T13:04:46Z","receivedAt":"2016-02-12T13:04:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 12, 2016 at 08:10:34AM +0100, Matthieu Moy wrote:\n\n> So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not\n> much, but it starts looking like last year ... ;-).\n> \n> Peff, would you be willing to co-admin with me (that would be cool, you\n> are the one with most experience here and you know the SFC stuff for\n> payment)? Are there any other co-admin volunteer?\n\nYes, I'm willing to co-admin (though I'm also happy to step aside for\nsomebody else if they would like to do it).\n\nThe biggest task there is getting the application together. I went\nthrough the account creation steps at the site (which is different this\nyear), and the application questions are:\n\n - Why does your org want to participate in Google Summer of Code?\n\n - How many potential mentors have agreed to mentor this year?\n\n - How will you keep mentors engaged with their students?\n\n - How will you help your students stay on schedule to complete their projects?\n\n - How will you get your students involved in your community during GSoC?\n\n - How will you keep students involved with your community after GSoC?\n\n - Has your org been accepted as a mentoring org in Google Summer of Code before?\n\n - Are you part of a foundation/umbrella organization?\n\n - What year was your project started? \n\nI think we can pull most of these answers from previous-year\napplications, but I haven't looked yet. In years past we collaborated on\nthe answers via the git.github.io site, and I pasted them in place.\n\n-Peff\n"},{"id":"278006","messageId":"20160212131126.GA12210@sigill.intra.peff.net","threadId":"41380","inReplyTo":"20160212130446.GB10858@sigill.intra.peff.net","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-12T13:11:27Z","receivedAt":"2016-02-12T13:11:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 12, 2016 at 08:04:46AM -0500, Jeff King wrote:\n\n> The biggest task there is getting the application together. I went\n> through the account creation steps at the site (which is different this\n> year), and the application questions are:\n> [...]\n\nWe also need to fill out our profile. Those items are listed below.\n\nMatthieu, I listed you as a co-mentor, so I think it will have sent you\nan email to join the application I started (hopefully you didn't do the\nexact same thing already... :) ).\n\n - Website URL\n\n - Tagline\n\n - Logo\n\n - Primary Open Source License\n\n - Organization Category\n\n - Technology Tags\n\n - Topic Tags\n\n - Ideas List\n\n - Short Description\n\n - Long Description\n\n - Application Instructions\n\n - Proposal Tags\n\n - IRC Channel, Mailing List, or Email \n\nThe big thing there is the ideas list.\n\n-Peff\n"},{"id":"278066","messageId":"vpqd1s04zzs.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"20160212130446.GB10858@sigill.intra.peff.net","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-13T11:21:43Z","receivedAt":"2016-02-13T11:21:43Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> On Fri, Feb 12, 2016 at 08:10:34AM +0100, Matthieu Moy wrote:\n>\n>> So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not\n>> much, but it starts looking like last year ... ;-).\n>> \n>> Peff, would you be willing to co-admin with me (that would be cool, you\n>> are the one with most experience here and you know the SFC stuff for\n>> payment)? Are there any other co-admin volunteer?\n>\n> Yes, I'm willing to co-admin (though I'm also happy to step aside for\n> somebody else if they would like to do it).\n\nCool!\n\n> The biggest task there is getting the application together. I went\n> through the account creation steps at the site (which is different this\n> year), and the application questions are:\n>\n> - Why does your org want to participate in Google Summer of Code?\n>\n> - How many potential mentors have agreed to mentor this year?\n>\n> - How will you keep mentors engaged with their students?\n>\n> - How will you help your students stay on schedule to complete their projects?\n>\n> - How will you get your students involved in your community during GSoC?\n>\n> - How will you keep students involved with your community after GSoC?\n>\n> - Has your org been accepted as a mentoring org in Google Summer of Code before?\n>\n> - Are you part of a foundation/umbrella organization?\n>\n> - What year was your project started? \n>\n> I think we can pull most of these answers from previous-year\n> applications, but I haven't looked yet. In years past we collaborated\n> on the answers via the git.github.io site, and I pasted them in place.\n\nI started working on it.\n\nhttp://git.github.io/SoC-2015-Org-Application/ => the application itself.\nMostly cut-and-paste from last year, but the questions have changed a\nbit. There's a \"Remarks on the current state of the application\" section\nat the end for stuff I wasn't sure about.\n\nThis is the urgent part, we won't have an opportunity to modify it after\nthe deadline.\n\n\nLess urgent, but we need to add more stuff to be credible:\n\nhttp://git.github.io/SoC-2016-Ideas/ => Ideas page. I removed the\ncompleted project, and updated some other to reflect the current state\nof Git. I think \"Convert scripts to builtins\" is still feasible this\nyear, but probably harder (we can't say \"start with git-pull.sh\"\nanymore ...). Johannes: you're still interested I guess?\n\nhttp://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/.\nI think most projects are not valid anymore, and we need new ones.\n\nTo all: please contribute to these pages, either by sending patches here\n(CC: me and peff), pushing directly if you have access, or submitting\npull-requests. The repo is https://github.com/git/git.github.io/.\n\nThanks,\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278366","messageId":"CAGZ79kbUG73eo5YvedbVB0bmZduMeCWNpbCRK4Adr9XDebsbQQ@mail.gmail.com","threadId":"41380","inReplyTo":"vpqd1s04zzs.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-02-16T18:10:38Z","receivedAt":"2016-02-16T18:10:38Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Sat, Feb 13, 2016 at 3:21 AM, Matthieu Moy\n wrote:\n> Jeff King writes:\n>\n>> On Fri, Feb 12, 2016 at 08:10:34AM +0100, Matthieu Moy wrote:\n>>\n>>> So, that makes it 4 possible co-mentors, i.e. 2 potential slots. Not\n>>> much, but it starts looking like last year ... ;-).\n>>>\n>>> Peff, would you be willing to co-admin with me (that would be cool, you\n>>> are the one with most experience here and you know the SFC stuff for\n>>> payment)? Are there any other co-admin volunteer?\n>>\n>> Yes, I'm willing to co-admin (though I'm also happy to step aside for\n>> somebody else if they would like to do it).\n>\n> Cool!\n>\n>> The biggest task there is getting the application together. I went\n>> through the account creation steps at the site (which is different this\n>> year), and the application questions are:\n>>\n>> - Why does your org want to participate in Google Summer of Code?\n>>\n>> - How many potential mentors have agreed to mentor this year?\n>>\n>> - How will you keep mentors engaged with their students?\n>>\n>> - How will you help your students stay on schedule to complete their projects?\n>>\n>> - How will you get your students involved in your community during GSoC?\n>>\n>> - How will you keep students involved with your community after GSoC?\n>>\n>> - Has your org been accepted as a mentoring org in Google Summer of Code before?\n>>\n>> - Are you part of a foundation/umbrella organization?\n>>\n>> - What year was your project started?\n>>\n>> I think we can pull most of these answers from previous-year\n>> applications, but I haven't looked yet. In years past we collaborated\n>> on the answers via the git.github.io site, and I pasted them in place.\n>\n> I started working on it.\n>\n> http://git.github.io/SoC-2015-Org-Application/ => the application itself.\n> Mostly cut-and-paste from last year, but the questions have changed a\n> bit. There's a \"Remarks on the current state of the application\" section\n> at the end for stuff I wasn't sure about.\n>\n> This is the urgent part, we won't have an opportunity to modify it after\n> the deadline.\n>\n>\n> Less urgent, but we need to add more stuff to be credible:\n>\n> http://git.github.io/SoC-2016-Ideas/ => Ideas page. I removed the\n> completed project, and updated some other to reflect the current state\n> of Git. I think \"Convert scripts to builtins\" is still feasible this\n> year, but probably harder (we can't say \"start with git-pull.sh\"\n> anymore ...). Johannes: you're still interested I guess?\n\nI'd be interested to co-mentor a sh->C conversion.\n\nI think the git-rebase*.sh is a good start.\n\n$ wc -l git-rebase*.sh\n 101 git-rebase--am.sh\n 1296 git-rebase--interactive.sh\n 167 git-rebase--merge.sh\n 636 git-rebase.sh\n 2200 total\n\nSo start with rebase--am and rebase--merge to have the same amount\nof lines as git-pull.sh. I did not look at the code, just judging by\nthe lines of\ncode.\n\ngit-rebase.sh with 636 lines of code is quite a lot I would think.\n\nThen there is also git-bisect.sh with nearly 700 lines, which is also not\nas easy.\n\nThanks,\nStefan\n\n>\n> http://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/.\n> I think most projects are not valid anymore, and we need new ones.\n>\n> To all: please contribute to these pages, either by sending patches here\n> (CC: me and peff), pushing directly if you have access, or submitting\n> pull-requests. The repo is https://github.com/git/git.github.io/.\n>\n> Thanks,\n>\n> --\n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n"},{"id":"278447","messageId":"vpqio1nsk0q.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"CAGZ79kbUG73eo5YvedbVB0bmZduMeCWNpbCRK4Adr9XDebsbQQ@mail.gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-17T10:34:13Z","receivedAt":"2016-02-17T10:34:13Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Stefan Beller writes:\n\n> I'd be interested to co-mentor a sh->C conversion.\n>\n> I think the git-rebase*.sh is a good start.\n>\n> $ wc -l git-rebase*.sh\n> 101 git-rebase--am.sh\n> 1296 git-rebase--interactive.sh\n> 167 git-rebase--merge.sh\n> 636 git-rebase.sh\n> 2200 total\n>\n> So start with rebase--am and rebase--merge to have the same amount\n> of lines as git-pull.sh. I did not look at the code, just judging by\n> the lines of\n> code.\n\nThere's a funny exercice there: the git-rebase--$type.sh scripts are not\ncalled as external helpers, but like this:\n\nrun_specific_rebase () {\n\tif [ \"$interactive_rebase\" = implied ]; then\n\t\tGIT_EDITOR=:\n\t\texport GIT_EDITOR\n\t\tautosquash=\n\tfi\n\t. git-rebase--$type\n\t# ...\n\nSo, turning these scripts into builtins would first require turning this\n\". git-rebase--$type\" into an actual command call. But nothing\nunfeasible.\n\nAnyway, I'm not happy with the current shape of the code since\n.-including files within a function already caused us several issues (I\nfixed a FreeBSD related bug which triggered another one, so the current\ncode is a fix for a workaround for a FreeBSD issue ...).\n\nI guess git-rebase--interactive.sh would be a lot for a single GSoC\nproject, but it can remain a shell-script helper called by a builtin.\n\nCan you add more details to the \"Convert scripts to builtins\" part of\nhttp://git.github.io/SoC-2016-Ideas/ to reflect this? And make it look\nattractive for candidates ;-).\n\nThanks,\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278450","messageId":"CACsJy8BGTQOGfOMcx6pnf6hfry4LojxXsWp-TaNyem-6j4USLw@mail.gmail.com","threadId":"41380","inReplyTo":"vpqio1nsk0q.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-17T10:45:40Z","receivedAt":"2016-02-17T10:45:40Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 17, 2016 at 5:34 PM, Matthieu Moy\n wrote:\n> Stefan Beller writes:\n>\n>> I'd be interested to co-mentor a sh->C conversion.\n>>\n>> I think the git-rebase*.sh is a good start.\n>>\n>> $ wc -l git-rebase*.sh\n>> 101 git-rebase--am.sh\n>> 1296 git-rebase--interactive.sh\n>> 167 git-rebase--merge.sh\n>> 636 git-rebase.sh\n>> 2200 total\n>>\n>> So start with rebase--am and rebase--merge to have the same amount\n>> of lines as git-pull.sh. I did not look at the code, just judging by\n>> the lines of\n>> code.\n>\n> There's a funny exercice there: the git-rebase--$type.sh scripts are not\n> called as external helpers, but like this:\n>\n> run_specific_rebase () {\n> if [ \"$interactive_rebase\" = implied ]; then\n> GIT_EDITOR=:\n> export GIT_EDITOR\n> autosquash=\n> fi\n> . git-rebase--$type\n> # ...\n>\n> So, turning these scripts into builtins would first require turning this\n> \". git-rebase--$type\" into an actual command call. But nothing\n> unfeasible.\n\nYeah we can turn those git-rebase--*.sh into separate actual programs,\nthen we can convert git-rebase.sh to C and other subprograms at a\nlater time. I started something back in 2013 [1] but never managed to\nfinish it. Also see the abandoned rewrite effort [2] from git for\nwindows\n\n[1] https://github.com/pclouds/git/commits/rebase-rewrite\n[2] https://github.com/git-for-windows/git/pull/461\n-- \nDuy\n"},{"id":"278451","messageId":"alpine.DEB.2.20.1602171353260.6516@virtualbox","threadId":"41380","inReplyTo":"CAGZ79kbUG73eo5YvedbVB0bmZduMeCWNpbCRK4Adr9XDebsbQQ@mail.gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-02-17T13:09:01Z","receivedAt":"2016-02-17T13:09:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stefan,\n\nOn Tue, 16 Feb 2016, Stefan Beller wrote:\n\n> I'd be interested to co-mentor a sh->C conversion.\n> \n> I think the git-rebase*.sh is a good start.\n> \n> $ wc -l git-rebase*.sh\n> 101 git-rebase--am.sh\n> 1296 git-rebase--interactive.sh\n> 167 git-rebase--merge.sh\n> 636 git-rebase.sh\n> 2200 total\n> \n> So start with rebase--am and rebase--merge to have the same amount\n> of lines as git-pull.sh. I did not look at the code, just judging by\n> the lines of\n> code.\n> \n> git-rebase.sh with 636 lines of code is quite a lot I would think.\n\nAs pointed out by Matthieu, starting with `git-rebase.sh` would be the\nwrong way round.\n\nIn addition, I would like to point out that turning shell scripts into\nbuiltins is not only hard work, it is also very dull. Maybe we can offer\nGSoC students something more exciting, and *just maybe* they'll stick\naround longer (I am amazed how active Karthik is, for example).\n\n> Then there is also git-bisect.sh with nearly 700 lines, which is also\n> not as easy.\n\nNothing is easy, but bisect has a much better chance to be finally\nconverted into a builtin: there is already a bisect--helper builtin, and\nall we need to do is to move more parts over, piece by piece. It does not\neven have to be a complete rewrite.\n\nI count 22 functions with bisect_start and bisect_replay being the obvious\nelephants. Personally, I would recommend starting with bisect_next_check\n(which would imply get_terms and bisect_voc, of course). It could even be\na mini project for a prospective student.\n\nCiao,\nJohannes\n"},{"id":"278453","messageId":"1455716201-29784-1-git-send-email-pclouds@gmail.com","threadId":"41380","inReplyTo":"vpqio1nsk0q.fsf@anie.imag.fr","subject":"[PATCH 0/3] Turn git-rebase--*.sh to external helpers","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-17T13:36:38Z","receivedAt":"2016-02-17T13:36:38Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 17, 2016 at 5:34 PM, Matthieu Moy wrote:\n> There's a funny exercice there: the git-rebase--$type.sh scripts are not\n> called as external helpers, but like this:\n>\n> run_specific_rebase () {\n>         if [ \"$interactive_rebase\" = implied ]; then\n>                 GIT_EDITOR=:\n>                 export GIT_EDITOR\n>                 autosquash=\n>         fi\n>         . git-rebase--$type\n>         # ...\n>\n> So, turning these scripts into builtins would first require turning this\n> \". git-rebase--$type\" into an actual command call. But nothing\n> unfeasible.\n\nWe do want to turn all these scripts to C in the end, regardless if\nthe conversion is part of any GSoC. So I dug up my code and prepared\nthis. Now we need people to convert any git-rebase*.sh to C :)\n\nNguyễn Thái Ngọc Duy (3):\n rebase: move common functions to rebase--lib.sh\n rebase: move cleanup code to exit_rebase()\n rebase: turn git-rebase--*.sh into separate programs\n\n Makefile | 7 +--\n git-rebase--am.sh (mode +x) | 23 ++++----\n git-rebase--interactive.sh (mode +x) | 15 ++++++\n git-rebase--lib.sh (new +x) | 79 +++++++++++++++++++++++++++\n git-rebase--merge.sh (mode +x) | 14 +++++\n git-rebase.sh | 100 ++++++-----------------------------\n 6 files changed, 143 insertions(+), 95 deletions(-)\n mode change 100644 => 100755 git-rebase--am.sh\n mode change 100644 => 100755 git-rebase--interactive.sh\n create mode 100755 git-rebase--lib.sh\n mode change 100644 => 100755 git-rebase--merge.sh\n\n-- \n2.7.0.377.g4cd97dd\n"},{"id":"278454","messageId":"1455716201-29784-2-git-send-email-pclouds@gmail.com","threadId":"41380","inReplyTo":"1455716201-29784-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 1/3] rebase: move common functions to rebase--lib.sh","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-17T13:36:39Z","receivedAt":"2016-02-17T13:36:39Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"These functions are used by git-rebase--*.sh, which will be made\nseparate programs later. At that point, we can reinclude rebase--lib.sh\nto provide the functions without duplicating code.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n Makefile | 1 +\n git-rebase--lib.sh (new) | 41 +++++++++++++++++++++++++++++++++++++++++\n git-rebase.sh | 42 +-----------------------------------------\n 3 files changed, 43 insertions(+), 41 deletions(-)\n create mode 100644 git-rebase--lib.sh\n\ndiff --git a/Makefile b/Makefile\nindex fc2f1ab..1ee0ed3 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -496,6 +496,7 @@ SCRIPT_LIB += git-parse-remote\n SCRIPT_LIB += git-rebase--am\n SCRIPT_LIB += git-rebase--interactive\n SCRIPT_LIB += git-rebase--merge\n+SCRIPT_LIB += git-rebase--lib\n SCRIPT_LIB += git-sh-setup\n SCRIPT_LIB += git-sh-i18n\n \ndiff --git a/git-rebase--lib.sh b/git-rebase--lib.sh\nnew file mode 100644\nindex 0000000..8bec516\n--- /dev/null\n+++ b/git-rebase--lib.sh\n@@ -0,0 +1,41 @@\n+write_basic_state () {\n+\techo \"$head_name\" > \"$state_dir\"/head-name &&\n+\techo \"$onto\" > \"$state_dir\"/onto &&\n+\techo \"$orig_head\" > \"$state_dir\"/orig-head &&\n+\techo \"$GIT_QUIET\" > \"$state_dir\"/quiet &&\n+\ttest t = \"$verbose\" && : > \"$state_dir\"/verbose\n+\ttest -n \"$strategy\" && echo \"$strategy\" > \"$state_dir\"/strategy\n+\ttest -n \"$strategy_opts\" && echo \"$strategy_opts\" > \\\n+\t\t\"$state_dir\"/strategy_opts\n+\ttest -n \"$allow_rerere_autoupdate\" && echo \"$allow_rerere_autoupdate\" > \\\n+\t\t\"$state_dir\"/allow_rerere_autoupdate\n+\ttest -n \"$gpg_sign_opt\" && echo \"$gpg_sign_opt\" > \"$state_dir\"/gpg_sign_opt\n+}\n+\n+output () {\n+\tcase \"$verbose\" in\n+\t'')\n+\t\toutput=$(\"$@\" 2>&1 )\n+\t\tstatus=$?\n+\t\ttest $status != 0 && printf \"%s\\n\" \"$output\"\n+\t\treturn $status\n+\t\t;;\n+\t*)\n+\t\t\"$@\"\n+\t\t;;\n+\tesac\n+}\n+\n+move_to_original_branch () {\n+\tcase \"$head_name\" in\n+\trefs/*)\n+\t\tmessage=\"rebase finished: $head_name onto $onto\"\n+\t\tgit update-ref -m \"$message\" \\\n+\t\t\t$head_name $(git rev-parse HEAD) $orig_head &&\n+\t\tgit symbolic-ref \\\n+\t\t\t-m \"rebase finished: returning to $head_name\" \\\n+\t\t\tHEAD $head_name ||\n+\t\tdie \"$(gettext \"Could not move back to $head_name\")\"\n+\t\t;;\n+\tesac\n+}\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex cf60c43..dc29474 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -46,6 +46,7 @@ edit-todo! edit the todo list during an interactive rebase\n \"\n . git-sh-setup\n . git-sh-i18n\n+. git-rebase--lib\n set_reflog_action rebase\n require_work_tree_exists\n cd_to_toplevel\n@@ -114,47 +115,6 @@ read_basic_state () {\n \t\tgpg_sign_opt=\"$(cat \"$state_dir\"/gpg_sign_opt)\"\n }\n \n-write_basic_state () {\n-\techo \"$head_name\" > \"$state_dir\"/head-name &&\n-\techo \"$onto\" > \"$state_dir\"/onto &&\n-\techo \"$orig_head\" > \"$state_dir\"/orig-head &&\n-\techo \"$GIT_QUIET\" > \"$state_dir\"/quiet &&\n-\ttest t = \"$verbose\" && : > \"$state_dir\"/verbose\n-\ttest -n \"$strategy\" && echo \"$strategy\" > \"$state_dir\"/strategy\n-\ttest -n \"$strategy_opts\" && echo \"$strategy_opts\" > \\\n-\t\t\"$state_dir\"/strategy_opts\n-\ttest -n \"$allow_rerere_autoupdate\" && echo \"$allow_rerere_autoupdate\" > \\\n-\t\t\"$state_dir\"/allow_rerere_autoupdate\n-\ttest -n \"$gpg_sign_opt\" && echo \"$gpg_sign_opt\" > \"$state_dir\"/gpg_sign_opt\n-}\n-\n-output () {\n-\tcase \"$verbose\" in\n-\t'')\n-\t\toutput=$(\"$@\" 2>&1 )\n-\t\tstatus=$?\n-\t\ttest $status != 0 && printf \"%s\\n\" \"$output\"\n-\t\treturn $status\n-\t\t;;\n-\t*)\n-\t\t\"$@\"\n-\t\t;;\n-\tesac\n-}\n-\n-move_to_original_branch () {\n-\tcase \"$head_name\" in\n-\trefs/*)\n-\t\tmessage=\"rebase finished: $head_name onto $onto\"\n-\t\tgit update-ref -m \"$message\" \\\n-\t\t\t$head_name $(git rev-parse HEAD) $orig_head &&\n-\t\tgit symbolic-ref \\\n-\t\t\t-m \"rebase finished: returning to $head_name\" \\\n-\t\t\tHEAD $head_name ||\n-\t\tdie \"$(gettext \"Could not move back to $head_name\")\"\n-\t\t;;\n-\tesac\n-}\n \n apply_autostash () {\n \tif test -f \"$state_dir/autostash\"\n-- \n2.7.0.377.g4cd97dd\n"},{"id":"278455","messageId":"1455716201-29784-3-git-send-email-pclouds@gmail.com","threadId":"41380","inReplyTo":"1455716201-29784-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 2/3] rebase: move cleanup code to exit_rebase()","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-17T13:36:40Z","receivedAt":"2016-02-17T13:36:40Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Signed-off-by: Nguyễn Thái Ngọc Duy \n---\n git-rebase--lib.sh (mode +x) | 38 ++++++++++++++++++++++++++++++++++++++\n git-rebase.sh | 37 +------------------------------------\n 2 files changed, 39 insertions(+), 36 deletions(-)\n mode change 100644 => 100755 git-rebase--lib.sh\n\ndiff --git a/git-rebase--lib.sh b/git-rebase--lib.sh\nold mode 100644\nnew mode 100755\nindex 8bec516..a876fc2\n--- a/git-rebase--lib.sh\n+++ b/git-rebase--lib.sh\n@@ -39,3 +39,41 @@ move_to_original_branch () {\n \t\t;;\n \tesac\n }\n+\n+apply_autostash () {\n+\tif test -f \"$state_dir/autostash\"\n+\tthen\n+\t\tstash_sha1=$(cat \"$state_dir/autostash\")\n+\t\tif git stash apply $stash_sha1 2>&1 >/dev/null\n+\t\tthen\n+\t\t\techo \"$(gettext 'Applied autostash.')\"\n+\t\telse\n+\t\t\tgit stash store -m \"autostash\" -q $stash_sha1 ||\n+\t\t\tdie \"$(eval_gettext \"Cannot store \\$stash_sha1\")\"\n+\t\t\tgettext 'Applying autostash resulted in conflicts.\n+Your changes are safe in the stash.\n+You can run \"git stash pop\" or \"git stash drop\" at any time.\n+'\n+\t\tfi\n+\tfi\n+}\n+\n+finish_rebase () {\n+\tapply_autostash &&\n+\t{ git gc --auto || true; } &&\n+\trm -rf \"$state_dir\"\n+}\n+\n+exit_rebase () {\n+\tret=$1\n+\tif test $ret -eq 0\n+\tthen\n+\t\tfinish_rebase\n+\telif test $ret -eq 2 # special exit status for rebase -i\n+\tthen\n+\t\tapply_autostash &&\n+\t\trm -rf \"$state_dir\" &&\n+\t\tdie \"Nothing to do\"\n+\tfi\n+\texit $ret\n+}\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex dc29474..0c70381 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -115,31 +115,6 @@ read_basic_state () {\n \t\tgpg_sign_opt=\"$(cat \"$state_dir\"/gpg_sign_opt)\"\n }\n \n-\n-apply_autostash () {\n-\tif test -f \"$state_dir/autostash\"\n-\tthen\n-\t\tstash_sha1=$(cat \"$state_dir/autostash\")\n-\t\tif git stash apply $stash_sha1 2>&1 >/dev/null\n-\t\tthen\n-\t\t\techo \"$(gettext 'Applied autostash.')\"\n-\t\telse\n-\t\t\tgit stash store -m \"autostash\" -q $stash_sha1 ||\n-\t\t\tdie \"$(eval_gettext \"Cannot store \\$stash_sha1\")\"\n-\t\t\tgettext 'Applying autostash resulted in conflicts.\n-Your changes are safe in the stash.\n-You can run \"git stash pop\" or \"git stash drop\" at any time.\n-'\n-\t\tfi\n-\tfi\n-}\n-\n-finish_rebase () {\n-\tapply_autostash &&\n-\t{ git gc --auto || true; } &&\n-\trm -rf \"$state_dir\"\n-}\n-\n run_specific_rebase () {\n \tif [ \"$interactive_rebase\" = implied ]; then\n \t\tGIT_EDITOR=:\n@@ -147,17 +122,7 @@ run_specific_rebase () {\n \t\tautosquash=\n \tfi\n \t. git-rebase--$type\n-\tret=$?\n-\tif test $ret -eq 0\n-\tthen\n-\t\tfinish_rebase\n-\telif test $ret -eq 2 # special exit status for rebase -i\n-\tthen\n-\t\tapply_autostash &&\n-\t\trm -rf \"$state_dir\" &&\n-\t\tdie \"Nothing to do\"\n-\tfi\n-\texit $ret\n+\texit_rebase $?\n }\n \n run_pre_rebase_hook () {\n-- \n2.7.0.377.g4cd97dd\n"},{"id":"278456","messageId":"1455716201-29784-4-git-send-email-pclouds@gmail.com","threadId":"41380","inReplyTo":"1455716201-29784-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 3/3] rebase: turn git-rebase--*.sh into separate programs","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-17T13:36:41Z","receivedAt":"2016-02-17T13:36:41Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"This is the first step of turning any of these scripts into C. We can\nsee now what variables are exchanged between git-rebase.sh and the\nsubscript (but we don't see all in this patch, variables may have been\nexported earlier in git-rebase.sh)\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n Makefile | 6 +++---\n git-rebase--am.sh (mode +x) | 23 ++++++++++++++---------\n git-rebase--interactive.sh (mode +x) | 15 +++++++++++++++\n git-rebase--merge.sh (mode +x) | 14 ++++++++++++++\n git-rebase.sh | 23 ++++++++++++++++-------\n 5 files changed, 62 insertions(+), 19 deletions(-)\n mode change 100644 => 100755 git-rebase--am.sh\n mode change 100644 => 100755 git-rebase--interactive.sh\n mode change 100644 => 100755 git-rebase--merge.sh\n\ndiff --git a/Makefile b/Makefile\nindex 1ee0ed3..ea636e6 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -486,6 +486,9 @@ SCRIPT_SH += git-mergetool.sh\n SCRIPT_SH += git-quiltimport.sh\n SCRIPT_SH += git-rebase.sh\n SCRIPT_SH += git-remote-testgit.sh\n+SCRIPT_SH += git-rebase--am.sh\n+SCRIPT_SH += git-rebase--interactive.sh\n+SCRIPT_SH += git-rebase--merge.sh\n SCRIPT_SH += git-request-pull.sh\n SCRIPT_SH += git-stash.sh\n SCRIPT_SH += git-submodule.sh\n@@ -493,9 +496,6 @@ SCRIPT_SH += git-web--browse.sh\n \n SCRIPT_LIB += git-mergetool--lib\n SCRIPT_LIB += git-parse-remote\n-SCRIPT_LIB += git-rebase--am\n-SCRIPT_LIB += git-rebase--interactive\n-SCRIPT_LIB += git-rebase--merge\n SCRIPT_LIB += git-rebase--lib\n SCRIPT_LIB += git-sh-setup\n SCRIPT_LIB += git-sh-i18n\ndiff --git a/git-rebase--am.sh b/git-rebase--am.sh\nold mode 100644\nnew mode 100755\nindex 9ae898b..3837f53\n--- a/git-rebase--am.sh\n+++ b/git-rebase--am.sh\n@@ -4,15 +4,19 @@\n # Copyright (c) 2010 Junio C Hamano.\n #\n \n-# The whole contents of this file is run by dot-sourcing it from\n-# inside a shell function. It used to be that \"return\"s we see\n-# below were not inside any function, and expected to return\n-# to the function that dot-sourced us.\n-#\n-# However, FreeBSD /bin/sh misbehaves on such a construct and\n-# continues to run the statements that follow such a \"return\".\n-# As a work-around, we introduce an extra layer of a function\n-# here, and immediately call it after defining it.\n+. git-sh-setup\n+. git-sh-i18n\n+. git-rebase--lib\n+require_work_tree_exists\n+\n+GIT_QUIET=$git_quiet\n+GIT_REFLOG_ACTION=$git_reflog_action\n+resolvemsg=\"\n+$(gettext 'When you have resolved this problem, run \"git rebase --continue\".\n+If you prefer to skip this patch, run \"git rebase --skip\" instead.\n+To check out the original branch and stop rebasing, run \"git rebase --abort\".')\n+\"\n+\n git_rebase__am () {\n \n case \"$action\" in\n@@ -99,3 +103,4 @@ move_to_original_branch\n }\n # ... and then we call the whole thing.\n git_rebase__am\n+exit_rebase $?\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nold mode 100644\nnew mode 100755\nindex c0cfe88..1169920\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -7,6 +7,20 @@\n # The original idea comes from Eric W. Biederman, in\n # http://article.gmane.org/gmane.comp.version-control.git/22407\n #\n+\n+. git-sh-setup\n+. git-sh-i18n\n+. git-rebase--lib\n+require_work_tree_exists\n+\n+GIT_QUIET=$git_quiet\n+GIT_REFLOG_ACTION=$git_reflog_action\n+resolvemsg=\"\n+$(gettext 'When you have resolved this problem, run \"git rebase --continue\".\n+If you prefer to skip this patch, run \"git rebase --skip\" instead.\n+To check out the original branch and stop rebasing, run \"git rebase --abort\".')\n+\"\n+\n # The file containing rebase commands, comments, and empty lines.\n # This file is created by \"git rebase -i\" then edited by the user. As\n # the lines are processed, they are removed from the front of this\n@@ -1294,3 +1308,4 @@ do_rest\n }\n # ... and then we call the whole thing.\n git_rebase__interactive\n+exit_rebase $?\ndiff --git a/git-rebase--merge.sh b/git-rebase--merge.sh\nold mode 100644\nnew mode 100755\nindex 2cc2a6d..f453d15\n--- a/git-rebase--merge.sh\n+++ b/git-rebase--merge.sh\n@@ -5,6 +5,19 @@\n # Copyright (c) 2010 Junio C Hamano.\n #\n \n+. git-sh-setup\n+. git-sh-i18n\n+. git-rebase--lib\n+require_work_tree_exists\n+\n+GIT_QUIET=$git_quiet\n+GIT_REFLOG_ACTION=$git_reflog_action\n+resolvemsg=\"\n+$(gettext 'When you have resolved this problem, run \"git rebase --continue\".\n+If you prefer to skip this patch, run \"git rebase --skip\" instead.\n+To check out the original branch and stop rebasing, run \"git rebase --abort\".')\n+\"\n+\n prec=4\n \n read_state () {\n@@ -165,3 +178,4 @@ finish_rb_merge\n }\n # ... and then we call the whole thing.\n git_rebase__merge\n+exit_rebase $?\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 0c70381..67b847f 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -54,11 +54,6 @@ cd_to_toplevel\n LF='\n '\n ok_to_skip_pre_rebase=\n-resolvemsg=\"\n-$(gettext 'When you have resolved this problem, run \"git rebase --continue\".\n-If you prefer to skip this patch, run \"git rebase --skip\" instead.\n-To check out the original branch and stop rebasing, run \"git rebase --abort\".')\n-\"\n unset onto\n unset restrict_revision\n cmd=\n@@ -121,8 +116,22 @@ run_specific_rebase () {\n \t\texport GIT_EDITOR\n \t\tautosquash=\n \tfi\n-\t. git-rebase--$type\n-\texit_rebase $?\n+\tgit_quiet=$GIT_QUIET\n+\tgit_reflog_action=$GIT_REFLOG_ACTION\n+\texport GIT_PAGER\n+\t# these are for write_basic_state()\n+\texport allow_rerere_autoupdate gpg_sign_opt head_name onto\n+\texport orig_head state_dir strategy strategy_opts verbose\n+\t# common variables\n+\texport action git_reflog_action git_quiet keep_empty\n+\texport rebase_root restrict_revision revisions upstream\n+\t# git-rebase--am specific\n+\texport git_am_opt\n+\t# git-rebase--interactive specific\n+\texport autosquash cmd force_rebase onto_name preserve_merges\n+\texport squash_onto switch_to\n+\n+\texec git-rebase--$type\n }\n \n run_pre_rebase_hook () {\n-- \n2.7.0.377.g4cd97dd\n"},{"id":"278458","messageId":"vpqk2m3juwo.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"1455716201-29784-3-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 2/3] rebase: move cleanup code to exit_rebase()","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-17T14:03:51Z","receivedAt":"2016-02-17T14:03:51Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> Signed-off-by: Nguyễn Thái Ngọc Duy \n\nThis patch could use a little bit more verbose commit message IMHO. At\nthis point it's not completely clear why you need to move this code to\ngit--rebase-lib.sh.\n\nMy understanding is that you want to have this code in the lib.h file to\nallow the toplevel to \"exec\" the helpers which does not allow the\ntoplevel to do the cleanup afterwards. Hence you need exit_rebase in the\nlib to call it from each helper.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278459","messageId":"vpqa8mzjuu9.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"1455716201-29784-4-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 3/3] rebase: turn git-rebase--*.sh into separate programs","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-17T14:05:18Z","receivedAt":"2016-02-17T14:05:18Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> +\tgit_quiet=$GIT_QUIET\n> +\tgit_reflog_action=$GIT_REFLOG_ACTION\n> +\texport GIT_PAGER\n> +\t# these are for write_basic_state()\n> +\texport allow_rerere_autoupdate gpg_sign_opt head_name onto\n> +\texport orig_head state_dir strategy strategy_opts verbose\n> +\t# common variables\n> +\texport action git_reflog_action git_quiet keep_empty\n> +\texport rebase_root restrict_revision revisions upstream\n> +\t# git-rebase--am specific\n> +\texport git_am_opt\n> +\t# git-rebase--interactive specific\n> +\texport autosquash cmd force_rebase onto_name preserve_merges\n> +\texport squash_onto switch_to\n> +\n> +\texec git-rebase--$type\n\nThis is a good first step, but we may later want to turn these\nenvironment variables into command-line options for the helpers. Or not.\n\nOn overall, the series looks good to me, but I don't have time for a\ndetailed review.\n\nThanks,\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278460","messageId":"alpine.DEB.2.20.1602171513140.6516@virtualbox","threadId":"41380","inReplyTo":"1455716201-29784-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 0/3] Turn git-rebase--*.sh to external helpers","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-02-17T14:22:55Z","receivedAt":"2016-02-17T14:22:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Feb 2016, Nguyễn Thái Ngọc Duy wrote:\n\n> We do want to turn all these scripts to C in the end, regardless if the\n> conversion is part of any GSoC. So I dug up my code and prepared this.\n> Now we need people to convert any git-rebase*.sh to C :)\n\nWhile I would love to see all these scripts to be converted to builtins, I\nthink that the proposed path would be too painful.\n\nI already started a different route locally (nothing to show yet, mostly\nbecause I have to write emails and try to triage the bug tracker instead\nof doing real work *grmbl*): add a rebase--helper and off-load heavy-duty\nwork from the scripts to that helper.\n\nThere are major benefits to do it that way:\n\n- we can focus on the really rewarding parts first, i.e. the parts that\n make the interactive rebase so painfully slow,\n\n- it allows for a painlessly incremental conversion,\n\n- if multiple people are interested in working on the conversion, it can\n happen in parallel.\n\nAnd probably a few other upsides.\n\nWill keep you posted when I have something to show,\nDscho"},{"id":"278462","messageId":"CACsJy8AAhpKbRi7QznwqAQ+uBb1SuFJCCh=cSw58oeuV1n_90g@mail.gmail.com","threadId":"41380","inReplyTo":"alpine.DEB.2.20.1602171513140.6516@virtualbox","subject":"Re: [PATCH 0/3] Turn git-rebase--*.sh to external helpers","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-17T14:40:32Z","receivedAt":"2016-02-17T14:40:32Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 17, 2016 at 9:22 PM, Johannes Schindelin\n wrote:\n> I already started a different route locally (nothing to show yet, mostly\n> because I have to write emails and try to triage the bug tracker instead\n> of doing real work *grmbl*): add a rebase--helper and off-load heavy-duty\n> work from the scripts to that helper.\n>\n> There are major benefits to do it that way:\n>\n> - we can focus on the really rewarding parts first, i.e. the parts that\n> make the interactive rebase so painfully slow,\n>\n> - it allows for a painlessly incremental conversion,\n>\n> - if multiple people are interested in working on the conversion, it can\n> happen in parallel.\n>\n> And probably a few other upsides.\n\nNow it does sound fun (and probably feel rewarding too), even to GSoC students!\n-- \nDuy\n"},{"id":"278463","messageId":"CAP8UFD2OY_QMqvEew5+V+P4653REm_P0R4_JiwwBfo0O6727Xw@mail.gmail.com","threadId":"41380","inReplyTo":"alpine.DEB.2.20.1602171353260.6516@virtualbox","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2016-02-17T16:04:09Z","receivedAt":"2016-02-17T16:04:09Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Johannes,\n\nOn Wed, Feb 17, 2016 at 2:09 PM, Johannes Schindelin\n wrote:\n>\n>> Then there is also git-bisect.sh with nearly 700 lines, which is also\n>> not as easy.\n>\n> Nothing is easy, but bisect has a much better chance to be finally\n> converted into a builtin: there is already a bisect--helper builtin, and\n> all we need to do is to move more parts over, piece by piece. It does not\n> even have to be a complete rewrite.\n\nI don't know which has a better chance to be finally converted, but\nit's true that for bisect, the bisect--helper builtin could help, and\nit can be done piece by piece.\n\n\n> I count 22 functions with bisect_start and bisect_replay being the obvious\n> elephants. Personally, I would recommend starting with bisect_next_check\n> (which would imply get_terms and bisect_voc, of course). It could even be\n> a mini project for a prospective student.\n\nNot sure it is small enough for a mini project, but sure it is a good\nchoice to start with.\n\nThanks,\nChristian.\n"},{"id":"278468","messageId":"20160217172407.GD1831@hank","threadId":"41380","inReplyTo":"vpqoabox66p.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2016-02-17T17:24:07Z","receivedAt":"2016-02-17T17:24:07Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 02/10, Matthieu Moy wrote:\n> Work on the application itself, and on the list of ideas.\n\nOne potential idea:\n\nMake destructive git commands more safe for the user.\n\nSome commands (e.g. git reset --hard, git clean -f, etc.) can\npotentially destroy some of the users work. Store the information\nthat we are potentially losing somewhere, where it's easily\nretrievable by the user.\n\nThis should probably be hidden behind a new config variable\n(core.iKnowWhatImDoingButIReallyDont or something better), as it has\nthe potential to really inflate the repository size (when storing\nbinary files that should be deleted by git clean for example).\n\nIt happened more than once that I thought I knew what I was doing, but\nwould have been really glad if git saved me from my mistakes.\n\nI haven't thought this through much further than just the idea, so it\nwould be great to hear some opinions on it first.\n"},{"id":"278487","messageId":"448280D1-3EEB-40DF-9886-C9B620E32E3C@gmail.com","threadId":"41380","inReplyTo":"20160217172407.GD1831@hank","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-02-17T18:32:05Z","receivedAt":"2016-02-17T18:32:05Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 17 Feb 2016, at 18:24, Thomas Gummerer wrote:\n\n> On 02/10, Matthieu Moy wrote:\n>> Work on the application itself, and on the list of ideas.\n> \n> One potential idea:\n> \n> Make destructive git commands more safe for the user.\n> \n> Some commands (e.g. git reset --hard, git clean -f, etc.) can\n> potentially destroy some of the users work. Store the information\n> that we are potentially losing somewhere, where it's easily\n> retrievable by the user.\n> \n> This should probably be hidden behind a new config variable\n> (core.iKnowWhatImDoingButIReallyDont or something better), as it has\n> the potential to really inflate the repository size (when storing\n> binary files that should be deleted by git clean for example).\n> \n> It happened more than once that I thought I knew what I was doing, but\n> would have been really glad if git saved me from my mistakes.\n> \n> I haven't thought this through much further than just the idea, so it\n> would be great to hear some opinions on it first.\n\nCoincidentally I started working on similar thing already (1) and I have\nlots of ideas around it. I get endless requests at my $DAYJOB of messed\nup Git repos where people just pasted stuff from StackOverflow without\na deep understanding of what they are doing.\n\nIf the lists agrees to take this topic for GSoC I would be happy to \nco-mentor it.\n\nCheers,\nLars\n\n(1) using Git config hacks\n\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"278488","messageId":"vpqh9h7f9kz.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"448280D1-3EEB-40DF-9886-C9B620E32E3C@gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-17T18:58:04Z","receivedAt":"2016-02-17T18:58:04Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Lars Schneider writes:\n\n> Coincidentally I started working on similar thing already (1) and I have\n> lots of ideas around it.\n\nI guess it's time to start sharing these ideas then ;-).\n\nI think there's a lot to do. If we want to push this idea as a GSoC\nproject, we need:\n\n* A rough plan. We can't expect students to read a vague text like\n \"let's make Git safer\" and write a real proposal out of it.\n\n* A way to start this rough plan incrementally (i.e. first step should\n be easy and mergeable without waiting for next steps).\n\nFeel free to start writting an idea for\nhttp://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more\nideas before Friday. We can polish them later if needed.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278490","messageId":"xmqq60xnjh1s.fsf@gitster.mtv.corp.google.com","threadId":"41380","inReplyTo":"vpqh9h7f9kz.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-17T19:03:11Z","receivedAt":"2016-02-17T19:03:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Feel free to start writting an idea for\n> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more\n> ideas before Friday. We can polish them later if needed.\n\nThe top of the page says it is shared between Git and libgit2;\nshould that be really the case? We later say we only have capacity\nfor two mentors, but the mentor pool capacity is not shared between\ntwo projects.\n\nI am wondering if we heard from libgit2 folks if they want us to\nhost them (or they want to participate in GSoC at all).\n"},{"id":"278498","messageId":"vpqziuzdr5r.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"xmqq60xnjh1s.fsf@gitster.mtv.corp.google.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-17T20:21:20Z","receivedAt":"2016-02-17T20:21:20Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> Feel free to start writting an idea for\n>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more\n>> ideas before Friday. We can polish them later if needed.\n>\n> The top of the page says it is shared between Git and libgit2;\n> should that be really the case? We later say we only have capacity\n> for two mentors, but the mentor pool capacity is not shared between\n> two projects.\n>\n> I am wondering if we heard from libgit2 folks if they want us to\n> host them (or they want to participate in GSoC at all).\n\nThe libgit2 mention is left from previous versions of this page. I left\na message on their IRC channel asking to join this thread if people were\ninterested (I don't know the libgit2 community really well, and I didn't\nfind a mailing-list to Cc here). \n\nI did not hear anything from them. We should probably remove the mention\nof libgit2. Or, if anyone receiving this message is interested in having\nlibgit2 participate, or knows anyone who may be, speak now.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278502","messageId":"20160217204528.GA22893@sigill.intra.peff.net","threadId":"41380","inReplyTo":"vpqziuzdr5r.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-17T20:45:28Z","receivedAt":"2016-02-17T20:45:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 17, 2016 at 09:21:20PM +0100, Matthieu Moy wrote:\n\n> > I am wondering if we heard from libgit2 folks if they want us to\n> > host them (or they want to participate in GSoC at all).\n> \n> The libgit2 mention is left from previous versions of this page. I left\n> a message on their IRC channel asking to join this thread if people were\n> interested (I don't know the libgit2 community really well, and I didn't\n> find a mailing-list to Cc here). \n> \n> I did not hear anything from them. We should probably remove the mention\n> of libgit2. Or, if anyone receiving this message is interested in having\n> libgit2 participate, or knows anyone who may be, speak now.\n\nI think they do a lot of their communication via GitHub issues. I've\ncc'd Carlos, the maintainer, who can ping the rest of the community as\nappropriate.\n\nI don't think we did a libgit2 project last year, and included the\nlibgit2 references mainly so that we would not drop them with zero\nwarning.\n\n-Peff\n"},{"id":"278511","messageId":"xmqq60xnhviw.fsf@gitster.mtv.corp.google.com","threadId":"41380","inReplyTo":"20160217204528.GA22893@sigill.intra.peff.net","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-17T21:33:27Z","receivedAt":"2016-02-17T21:33:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Feb 17, 2016 at 09:21:20PM +0100, Matthieu Moy wrote:\n>\n>> > I am wondering if we heard from libgit2 folks if they want us to\n>> > host them (or they want to participate in GSoC at all).\n>> \n>> The libgit2 mention is left from previous versions of this page. I left\n>> a message on their IRC channel asking to join this thread if people were\n>> interested (I don't know the libgit2 community really well, and I didn't\n>> find a mailing-list to Cc here). \n>> \n>> I did not hear anything from them. We should probably remove the mention\n>> of libgit2. Or, if anyone receiving this message is interested in having\n>> libgit2 participate, or knows anyone who may be, speak now.\n>\n> I think they do a lot of their communication via GitHub issues. I've\n> cc'd Carlos, the maintainer, who can ping the rest of the community as\n> appropriate.\n>\n> I don't think we did a libgit2 project last year, and included the\n> libgit2 references mainly so that we would not drop them with zero\n> warning.\n\nUnderstandable. I do not mind seeing us hosting them if that is\nwhat they want, but the candidate selection and mentor assignment\nbetween two more-or-less independent projects would not work very\nwell unless there is _some_ degree of coordination ;-)\n"},{"id":"278554","messageId":"1CE3F5E2-DDCC-4F1B-93CF-1A4A194650BF@gmail.com","threadId":"41380","inReplyTo":"vpqh9h7f9kz.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-02-18T08:41:00Z","receivedAt":"2016-02-18T08:41:00Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 17 Feb 2016, at 19:58, Matthieu Moy wrote:\n\n> Lars Schneider writes:\n> \n>> Coincidentally I started working on similar thing already (1) and I have\n>> lots of ideas around it.\n> \n> I guess it's time to start sharing these ideas then ;-).\n> \n> I think there's a lot to do. If we want to push this idea as a GSoC\n> project, we need:\n> \n> * A rough plan. We can't expect students to read a vague text like\n> \"let's make Git safer\" and write a real proposal out of it.\n> \n> * A way to start this rough plan incrementally (i.e. first step should\n> be easy and mergeable without waiting for next steps).\n> \n> Feel free to start writting an idea for\n> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more\n> ideas before Friday. We can polish them later if needed.\n\nI published my ideas here:\nhttps://github.com/git/git.github.io/pull/125/files\n\nDo you think that works as start or do we need more detailed, hands-on\ninstructions?\n\nThanks,\nLars\n"},{"id":"278558","messageId":"1455788324.3786.14.camel@dwim.me","threadId":"41380","inReplyTo":"xmqq60xnhviw.fsf@gitster.mtv.corp.google.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Carlos Martín Nieto","fromEmail":"cmn@dwim.me","sentAt":"2016-02-18T09:38:44Z","receivedAt":"2016-02-18T09:38:44Z","isPatch":false,"sender":{"key":"cmn@dwim.me","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Wed, 2016-02-17 at 13:33 -0800, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > On Wed, Feb 17, 2016 at 09:21:20PM +0100, Matthieu Moy wrote:\n> > \n> > > > I am wondering if we heard from libgit2 folks if they want us\n> > > > to\n> > > > host them (or they want to participate in GSoC at all).\n> > > \n> > > The libgit2 mention is left from previous versions of this page.\n> > > I left\n> > > a message on their IRC channel asking to join this thread if\n> > > people were\n> > > interested (I don't know the libgit2 community really well, and I\n> > > didn't\n> > > find a mailing-list to Cc here). \n> > > \n> > > I did not hear anything from them. We should probably remove the\n> > > mention\n> > > of libgit2. Or, if anyone receiving this message is interested in\n> > > having\n> > > libgit2 participate, or knows anyone who may be, speak now.\n> > \n> > I think they do a lot of their communication via GitHub issues.\n> > I've\n> > cc'd Carlos, the maintainer, who can ping the rest of the community\n> > as\n> > appropriate.\n> > \n> > I don't think we did a libgit2 project last year, and included the\n> > libgit2 references mainly so that we would not drop them with zero\n> > warning.\n> \n> Understandable.  I do not mind seeing us hosting them if that is\n> what they want, but the candidate selection and mentor assignment\n> between two more-or-less independent projects would not work very\n> well unless there is _some_ degree of coordination ;-)\n\nWe still have most of the same things open as for the 2014 list. I'll\nask around to see if we have. Last year I wasn't involved in the\ncandidate selection but IIRC we didn't do a project as none of the\napplications showed the candidates would be capable of doing the\nproject they were applying for.\n\nI'll ask around to make sure people would be able to be mentors, but I\nthink that we would still like to put forward a few projects (I can\nsend a PR with the projects that we would still like to see to the 2016\npage).\n\nCheers,\n   cmn\n"},{"id":"278566","messageId":"CAGZ79kbGyCTdq4P02fNb7tEuvkvqcZviWJp40Ob1ed6=JCh9Xg@mail.gmail.com","threadId":"41380","inReplyTo":"1CE3F5E2-DDCC-4F1B-93CF-1A4A194650BF@gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-02-18T18:38:28Z","receivedAt":"2016-02-18T18:38:28Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Feb 18, 2016 at 12:41 AM, Lars Schneider\n wrote:\n>> Feel free to start writting an idea for\n>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more\n>> ideas before Friday. We can polish them later if needed.\n>\n> I published my ideas here:\n> https://github.com/git/git.github.io/pull/125/files\n\nI like the idea of a beginner mode, but on the other hand that looks\ninflexible to me ;)\n(What if I want to use rebase, but not reset --hard?)\nI am confused by the black white mode, did you switch allow and deny in there?\n\n\n>\n> Do you think that works as start or do we need more detailed, hands-on\n> instructions?\n>\n> Thanks,\n> Lars\n"},{"id":"278567","messageId":"xmqq7fi1hlw6.fsf@gitster.mtv.corp.google.com","threadId":"41380","inReplyTo":"CAGZ79kbGyCTdq4P02fNb7tEuvkvqcZviWJp40Ob1ed6=JCh9Xg@mail.gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-18T19:13:45Z","receivedAt":"2016-02-18T19:13:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> On Thu, Feb 18, 2016 at 12:41 AM, Lars Schneider\n> wrote:\n>>> Feel free to start writting an idea for\n>>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more\n>>> ideas before Friday. We can polish them later if needed.\n>>\n>> I published my ideas here:\n>> https://github.com/git/git.github.io/pull/125/files\n>\n> I like the idea of a beginner mode, but on the other hand that looks\n> inflexible to me ;)\n> (What if I want to use rebase, but not reset --hard?)\n\nThat's simple. You say \"cd .. && rm -fr repo && git clone\" and\nstart from scratch ;-).\n\nThis whole \"beginner should be limited to a 'safe' subset\" is an\nunhealthy attitude.\n\nDeciding what the 'safe' subset is must be done with a lot of\nthinking by people who intimately know what implications it has to\nban each feature. I do not think it would be a good fit for a\nproject to give to a relatively new participant to the Git project.\n\nFor example, I think banning \"worktree\" feature from newbies may not\nbe a bad idea, as you can work on a project without using \"worktree\"\nat all, and use of \"worktree\" would only subject you to bugs that do\nnot exist when you do not use that feature. The \"shallow clone\",\n\"sparse checkout\", and \"untracked cache\" fall into the same category\nfor exactly the same reason. The \"submodule\" feature might fall\ninto the same category for the same reason, but that is not\nsomething you as a project participant can unilaterally decide, as\nthe project you are working on may have already decided to use the\nfeature, so it is harder to ban from the beginners.\n\nBut for the rest of really \"core\" part of Git, I do not think there\nis any such command that can be totally banned.\n\nWe have these \"powerful\" tools for a reason. After making a mess\nexperimenting with your working tree files, \"reset --hard\" is the\nbest tool to go back to the known-good state, and robbing it from\nthe users is not a sound approach to help them. When \"powerful\"\nbecomes \"too powerful\" is when a \"powerful\" tool is misused. It is\nperhaps done by mistake or perhaps done by copying and pasting a\nsolution from Interweb for a problem that does not match your\nsituation without understanding what you are doing.\n\nWhat is needed to help beginners is to make the powerful tool harder\nto misuse. Of course, that would be a harder task, because you have\nto do a real thinking.\n\nYou do not have to do any thinking to say that \"a blanket ban that\nhides these powerful tools behind the beginner mode\" helps\nbeginners, but I do not think it is solving what really matters. At\nthe same time, it just adds to the FUD, i.e. some commands are too\npowerful for their own good.\n"},{"id":"278607","messageId":"CACsJy8D-bHOLGKq0ZELcPYWpKXgct3HBF9Btp3UPw+tqGUR5Bw@mail.gmail.com","threadId":"41380","inReplyTo":"vpqh9h7f9kz.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-19T03:09:45Z","receivedAt":"2016-02-19T03:09:45Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Feb 18, 2016 at 1:58 AM, Matthieu Moy\n wrote:\n> Feel free to start writting an idea for\n> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more\n> ideas before Friday. We can polish them later if needed.\n\nProbably too late now, anyway.. with David's multiple ref backend\nwork, we could have a third, no-dependency backend. We can use index\nformat to store refs. Then we can avoid case-sensitivity issue with\nfilesystems. Split-index could make it relatively cheap for updating\nrefs. Later on, when we can store tree objects in index (*), some\n(rarely used) refs could be stored as tree objects and we can reduce\nindex file size (and loading cost). This idea is inspired by Shawn's\nstoring refs as tree objects mail, except that I stopped at \"wait, if\nwe want to create trees we (usually) have to go through index, why not\njust stop at index?\".\n\n(*) In have some WIP in this area, but not ready for public discussion\nyet. And it's out of scope for GSoC.\n-- \nDuy\n"},{"id":"278609","messageId":"xmqq7fi1e688.fsf@gitster.mtv.corp.google.com","threadId":"41380","inReplyTo":"CACsJy8D-bHOLGKq0ZELcPYWpKXgct3HBF9Btp3UPw+tqGUR5Bw@mail.gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-19T03:20:23Z","receivedAt":"2016-02-19T03:20:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> Probably too late now, anyway.. with David's multiple ref backend\n> work, we could have a third, no-dependency backend. We can use index\n> format to store refs. Then we can avoid case-sensitivity issue with\n> filesystems.\n\nI'd actually vote for a ref backend that is based on a tree object ;-)\n\n http://thread.gmane.org/gmane.comp.version-control.git/282677\n"},{"id":"278610","messageId":"CACsJy8Ah2VH8mE7wMi0pVvUDKq3ic7AkwmCPa4oGnDSMGcD-hA@mail.gmail.com","threadId":"41380","inReplyTo":"xmqq7fi1e688.fsf@gitster.mtv.corp.google.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-19T03:29:11Z","receivedAt":"2016-02-19T03:29:11Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Feb 19, 2016 at 10:20 AM, Junio C Hamano wrote:\n> Duy Nguyen writes:\n>\n>> Probably too late now, anyway.. with David's multiple ref backend\n>> work, we could have a third, no-dependency backend. We can use index\n>> format to store refs. Then we can avoid case-sensitivity issue with\n>> filesystems.\n>\n> I'd actually vote for a ref backend that is based on a tree object ;-)\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/282677\n\nFor reasonably small sets of refs I think index beats trees (remember\nwe have cache-tree, which basically gives us the tree behind the\nscene), but when you have so many refs, hierarchical storage may be\nmore efficient. Either way it's nice to see a builtin, no dependency\nbackend besides \"files\".\n-- \nDuy\n"},{"id":"278614","messageId":"vpq60xl88zk.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"CACsJy8D-bHOLGKq0ZELcPYWpKXgct3HBF9Btp3UPw+tqGUR5Bw@mail.gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-19T07:17:19Z","receivedAt":"2016-02-19T07:17:19Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Duy Nguyen writes:\n\n> On Thu, Feb 18, 2016 at 1:58 AM, Matthieu Moy\n> wrote:\n>> Feel free to start writting an idea for\n>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more\n>> ideas before Friday. We can polish them later if needed.\n>\n> Probably too late now, anyway..\n\nIt's still time. I'll post the application very soon (a few hours from\nnow), but the idea list is not included in the application, but linked\nfrom it. So we can add something before reviewers follow the link, and\nobviously we can add more before students start picking them.\n\n> with David's multiple ref backend work, we could have a third,\n> no-dependency backend. We can use index format to store refs.\n\nThis sounds like an interesting but ambitious project for a GSoC. There\nare a lot of new stuff to understand for someone potentially new to\nGit's codebase. And it's hard to work incrementally: the result would\nhardly be mergeable before being almost finished.\n\nI think it's interesting to offer the idea, but there should be a\nwarning for the student about the difficulties.\n\nWould you be willing to (co-)mentor?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278616","messageId":"vpqr3g96tn6.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"xmqq7fi1hlw6.fsf@gitster.mtv.corp.google.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-19T07:34:05Z","receivedAt":"2016-02-19T07:34:05Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Deciding what the 'safe' subset is must be done with a lot of\n> thinking by people who intimately know what implications it has to\n> ban each feature. I do not think it would be a good fit for a\n> project to give to a relatively new participant to the Git project.\n\nI have to agree with this: this would actually be very hard to get a\nnice proposal from a student. Students can be good technically, but we\ncan't expect them to be experienced and giving sound advices to\nbeginners is hard in this situation.\n\n> We have these \"powerful\" tools for a reason. After making a mess\n> experimenting with your working tree files, \"reset --hard\" is the\n> best tool to go back to the known-good state,\n\nI disagree with that. This reminds me a discussion I had with a student\na few years ago:\n\n student: how do a clear all changes from my worktree?\n me: git reset --hard\n\nthe next day:\n\n student: OK, now, how do I get my changes back?\n me: ...!\n\nThere's almost no situation where reset --hard is the best tool. If you\njust want to discard local changes, then \"stash\" is much safer (it'll\neat a bit of your disk space, but in 99% cases it's not an issue). If\nyou messed up a merge then \"merge --abort\" is safer. If the goal is to\nmove HEAD, then \"reset --keep\" is safer.\n\nOne thing I like about Git is: when a beginner messes up his tree or\nrepo, his Git guru friend can almost always repair it easily (at least,\nmuch easier than it was with svn). But there are still a few ways for\nbeginners to shoot themselves in the foot in a way that the guru cannot\nrepair.\n\n\nNow, another issue with the proposed core.isbeginner is compatibility\nwith scripts. Dangerous commands are often plumbing, and a beginner may\nstill want to use scripts or other porcelain on top of it. Typically, I\nthink this rules out \"git reset --hard\" which is legitimate in scripts.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278619","messageId":"vpq1t896s5c.fsf_-_@anie.imag.fr","threadId":"41380","inReplyTo":"1455788324.3786.14.camel@dwim.me","subject":"Re: GSoC 2016: applications open, libgit2 and git.git","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-19T08:06:23Z","receivedAt":"2016-02-19T08:06:23Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Carlos Martín Nieto writes:\n\n> We still have most of the same things open as for the 2014 list. I'll\n> ask around to see if we have. Last year I wasn't involved in the\n> candidate selection but IIRC we didn't do a project as none of the\n> applications showed the candidates would be capable of doing the\n> project they were applying for.\n\nOK. It's essentially too late to change this for this year, but next\ntime we should discuss earlier about how we want to organize this\ngit.git/libgit2 thing. For example, I think it would make little sense\nto have a git.git microproject and then apply for a libgit2 project\nsince we have very different ways of interacting. And honnestly, right\nnow the application is really git.git-centric so I don't think it\nattracts students towards libgit2. So, if you want to attract more\nstudents, we should work on that.\n\nI tried to clarify the situation with libgit2:\n\nhttps://github.com/git/git.github.io/commit/94d1747eb9621b3bc892be2f232338b7933ac271\n\nPlease say if you're happy/unhappy with what I wrote. PRs are still\nwelcome after the deadline.\n\n> I'll ask around to make sure people would be able to be mentors, but I\n> think that we would still like to put forward a few projects (I can\n> send a PR with the projects that we would still like to see to the 2016\n> page).\n\nWe don't have this everywhere, but having a \"potential mentors\" field\nfor projects also helps (students, and us, at least to make sure we do\nhave mentors).\n\nCheers,\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278620","messageId":"vpqr3g95df5.fsf_-_@anie.imag.fr","threadId":"41380","inReplyTo":"1455788324.3786.14.camel@dwim.me","subject":"Re: GSoC 2016: applications open, deadline = now => submission","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-19T08:09:50Z","receivedAt":"2016-02-19T08:09:50Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Hi,\n\nThe deadline is tonight (19:00 UTC). I don't want to miss it, so I'll\nsubmit the application very soon based on\nhttp://git.github.io/SoC-2016-Org-Application/.\n\nOther pages can still be modified afterwards.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278621","messageId":"20160219081848.GB780@sigill.intra.peff.net","threadId":"41380","inReplyTo":"vpqr3g95df5.fsf_-_@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = now => submission","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-19T08:18:48Z","receivedAt":"2016-02-19T08:18:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 19, 2016 at 09:09:50AM +0100, Matthieu Moy wrote:\n\n> Hi,\n> \n> The deadline is tonight (19:00 UTC). I don't want to miss it, so I'll\n> submit the application very soon based on\n> http://git.github.io/SoC-2016-Org-Application/.\n\nI think we can continue to modify up to the deadline (at least that has\nbeen the case in years past).\n\nBut I agree with getting something in place and iterating from there.\n\n-Peff\n"},{"id":"278624","messageId":"vpqsi0p3w0w.fsf_-_@anie.imag.fr","threadId":"41380","inReplyTo":"20160219081848.GB780@sigill.intra.peff.net","subject":"Re: GSoC 2016: applications open, deadline = now => submitted","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-19T09:10:55Z","receivedAt":"2016-02-19T09:10:55Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> On Fri, Feb 19, 2016 at 09:09:50AM +0100, Matthieu Moy wrote:\n>\n>> Hi,\n>> \n>> The deadline is tonight (19:00 UTC). I don't want to miss it, so I'll\n>> submit the application very soon based on\n>> http://git.github.io/SoC-2016-Org-Application/.\n>\n> I think we can continue to modify up to the deadline (at least that has\n> been the case in years past).\n\nIndeed: I've completed the application and it's still possible to modify\n(the form just says \"You've completed this form\", but there's no scary\n\"submit and remove write access from now\" button ;-)).\n\nI had to modify the text a bit to fit within the new length limit (1000\ncharacters for most fields). The content of the form should be the same\nas what's currently on http://git.github.io/SoC-2016-Org-Application/.\nPlease check.\n\nThanks,\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278630","messageId":"0E364888-DD95-4B47-9679-3CB586FC7E8C@gmail.com","threadId":"41380","inReplyTo":"xmqq7fi1hlw6.fsf@gitster.mtv.corp.google.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-02-19T09:23:56Z","receivedAt":"2016-02-19T09:23:56Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 18 Feb 2016, at 20:13, Junio C Hamano wrote:\n\n> Stefan Beller writes:\n> \n>> On Thu, Feb 18, 2016 at 12:41 AM, Lars Schneider\n>> wrote:\n>>>> Feel free to start writting an idea for\n>>>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more\n>>>> ideas before Friday. We can polish them later if needed.\n>>> \n>>> I published my ideas here:\n>>> https://github.com/git/git.github.io/pull/125/files\n>> \n>> I like the idea of a beginner mode, but on the other hand that looks\n>> inflexible to me ;)\n>> (What if I want to use rebase, but not reset --hard?)\n> \n> That's simple. You say \"cd .. && rm -fr repo && git clone\" and\n> start from scratch ;-).\n> \n> This whole \"beginner should be limited to a 'safe' subset\" is an\n> unhealthy attitude.\n> \n> Deciding what the 'safe' subset is must be done with a lot of\n> thinking by people who intimately know what implications it has to\n> ban each feature. I do not think it would be a good fit for a\n> project to give to a relatively new participant to the Git project.\n> \n> For example, I think banning \"worktree\" feature from newbies may not\n> be a bad idea, as you can work on a project without using \"worktree\"\n> at all, and use of \"worktree\" would only subject you to bugs that do\n> not exist when you do not use that feature. The \"shallow clone\",\n> \"sparse checkout\", and \"untracked cache\" fall into the same category\n> for exactly the same reason. The \"submodule\" feature might fall\n> into the same category for the same reason, but that is not\n> something you as a project participant can unilaterally decide, as\n> the project you are working on may have already decided to use the\n> feature, so it is harder to ban from the beginners.\n> \n> But for the rest of really \"core\" part of Git, I do not think there\n> is any such command that can be totally banned.\n> \n> We have these \"powerful\" tools for a reason. After making a mess\n> experimenting with your working tree files, \"reset --hard\" is the\n> best tool to go back to the known-good state, and robbing it from\n> the users is not a sound approach to help them. When \"powerful\"\n> becomes \"too powerful\" is when a \"powerful\" tool is misused. It is\n> perhaps done by mistake or perhaps done by copying and pasting a\n> solution from Interweb for a problem that does not match your\n> situation without understanding what you are doing.\n> \n> What is needed to help beginners is to make the powerful tool harder\n> to misuse. Of course, that would be a harder task, because you have\n> to do a real thinking.\n> \n> You do not have to do any thinking to say that \"a blanket ban that\n> hides these powerful tools behind the beginner mode\" helps\n> beginners, but I do not think it is solving what really matters. At\n> the same time, it just adds to the FUD, i.e. some commands are too\n> powerful for their own good.\n\nThanks for your elaborate response. I think I got your point and I\ntried to adjust my \"beginner mode\" proposal accordingly [1]. Here\nis the relevant change:\n\nIf this mode is enabled then Git shall print a warning message before \nrunning a potentially destructive command. In addition to the warning \nGit shall print a command that would reverse the operation if possible. \nMost of the information to reverse an operation is already available \nvia git reflog. However, the task here is to make this information more \neasily accessible to Git beginners.\n\n--\n\nDoes this go into the direction of \"making the powerful tool harder to\nmisuse\"?\n\nThanks,\nLars\n"},{"id":"278632","messageId":"CACsJy8AySJdgntW3hv+J9zuGMAKV5H4suLJp2jy_xRuGY=6evQ@mail.gmail.com","threadId":"41380","inReplyTo":"vpq60xl88zk.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-19T09:41:45Z","receivedAt":"2016-02-19T09:41:45Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Feb 19, 2016 at 2:17 PM, Matthieu Moy\n wrote:\n>> with David's multiple ref backend work, we could have a third,\n>> no-dependency backend. We can use index format to store refs.\n>\n> This sounds like an interesting but ambitious project for a GSoC. There\n> are a lot of new stuff to understand for someone potentially new to\n> Git's codebase. And it's hard to work incrementally: the result would\n> hardly be mergeable before being almost finished.\n\nOn the other hand, the actual amount of code they write is roughly\nabout 1700 lines of refs/lmdb-backend.c. Which I guess can be written\nin a month once you know what's going on, basically how refs are\nhandled (I think documents have been greatly improved), git object\nmanipulation and optionally index manipulation (if we store in index\ninstead of trees). I think it's manageable. But then I haven't\ninteracted with students for a looong time.\n\n> I think it's interesting to offer the idea, but there should be a\n> warning for the student about the difficulties.\n\nYep.\n\n> Would you be willing to (co-)mentor?\n\nI can't guarantee I will not disappear for a couple months again like\nlast year. It depends on $DAY_JOB. So maybe co-mentor position, but my\nother co-mentor should be ready for that situation.\n-- \nDuy\n"},{"id":"278634","messageId":"1455875178.343346.31.camel@dwim.me","threadId":"41380","inReplyTo":"vpq1t896s5c.fsf_-_@anie.imag.fr","subject":"Re: GSoC 2016: applications open, libgit2 and git.git","fromName":"Carlos Martín Nieto","fromEmail":"cmn@dwim.me","sentAt":"2016-02-19T09:46:18Z","receivedAt":"2016-02-19T09:46:18Z","isPatch":false,"sender":{"key":"cmn@dwim.me","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Fri, 2016-02-19 at 09:06 +0100, Matthieu Moy wrote:\n> Carlos Martín Nieto writes:\n> \n> > We still have most of the same things open as for the 2014 list.\n> > I'll\n> > ask around to see if we have. Last year I wasn't involved in the\n> > candidate selection but IIRC we didn't do a project as none of the\n> > applications showed the candidates would be capable of doing the\n> > project they were applying for.\n> \n> OK. It's essentially too late to change this for this year, but next\n> time we should discuss earlier about how we want to organize this\n> git.git/libgit2 thing. For example, I think it would make little\n> sense\n> to have a git.git microproject and then apply for a libgit2 project\n> since we have very different ways of interacting. And honnestly,\n> right\n> now the application is really git.git-centric so I don't think it\n> attracts students towards libgit2. So, if you want to attract more\n> students, we should work on that.\n> \n> I tried to clarify the situation with libgit2:\n> \n> https://github.com/git/git.github.io/commit/94d1747eb9621b3bc892be2f2\n> 32338b7933ac271\n> \n> Please say if you're happy/unhappy with what I wrote. PRs are still\n> welcome after the deadline.\n\nThis is fine. Our projects file should also be noted for the\nmicroprojects, but I'll write that up myself. I'm writing up the two\nprojects we've thought up as part of the ideas page and will send a PR\ntoday.\n\n   cmn\n"},{"id":"278660","messageId":"20160219113723.GA9568@sigill.intra.peff.net","threadId":"41380","inReplyTo":"vpqsi0p3w0w.fsf_-_@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = now => submitted","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-19T11:37:24Z","receivedAt":"2016-02-19T11:37:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 19, 2016 at 10:10:55AM +0100, Matthieu Moy wrote:\n\n> > I think we can continue to modify up to the deadline (at least that has\n> > been the case in years past).\n> \n> Indeed: I've completed the application and it's still possible to modify\n> (the form just says \"You've completed this form\", but there's no scary\n> \"submit and remove write access from now\" button ;-)).\n> \n> I had to modify the text a bit to fit within the new length limit (1000\n> characters for most fields). The content of the form should be the same\n> as what's currently on http://git.github.io/SoC-2016-Org-Application/.\n> Please check.\n\nI read over what is in Google's application system, and it all looks\ngood.\n\nI did make one minor change, which is that I listed \"Software Freedom\nConservancy\" as a foundation of which we are a member. I don't think it\nwill make a difference either way to our application, but they may want\nto have it in their system, as it becomes relevant later on for\ninvoicing the mentor payments.\n\nMatthieu, thanks for coordinating the application effort this year. And\nthanks to everybody else for submitting ideas and microprojects.\n\n-Peff\n"},{"id":"278661","messageId":"20160219114657.GG1831@hank","threadId":"41380","inReplyTo":"1CE3F5E2-DDCC-4F1B-93CF-1A4A194650BF@gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2016-02-19T11:46:57Z","receivedAt":"2016-02-19T11:46:57Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 02/18, Lars Schneider wrote:\n>\n> On 17 Feb 2016, at 19:58, Matthieu Moy wrote:\n>\n> > Lars Schneider writes:\n> >\n> >> Coincidentally I started working on similar thing already (1) and I have\n> >> lots of ideas around it.\n> >\n> > I guess it's time to start sharing these ideas then ;-).\n> >\n> > I think there's a lot to do. If we want to push this idea as a GSoC\n> > project, we need:\n> >\n> > * A rough plan. We can't expect students to read a vague text like\n> > \"let's make Git safer\" and write a real proposal out of it.\n> >\n> > * A way to start this rough plan incrementally (i.e. first step should\n> > be easy and mergeable without waiting for next steps).\n> >\n> > Feel free to start writting an idea for\n> > http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more\n> > ideas before Friday. We can polish them later if needed.\n>\n> I published my ideas here:\n> https://github.com/git/git.github.io/pull/125/files\n\nSorry for posting my idea so late, but it took me a while to write\nthis all up, and life has a habit of getting in the way. My idea goes\ninto a different direction than yours.\n\nI do like the remote whitelist/blacklist project.\n\nJunio pointed out to me off list that this is to complicated for a\nGSoC project. I kind of agree with that, but I wanted to see how this\ncould be split up, to completely convince myself as well. And indeed,\nthe more I think about it the more risky it seems.\n\nBelow there are some thoughts on a potential design, in case someone\nis interested, no code to back any of this up, sorry.\n\nEverything proposed below should be hidden behind some configuration\nvariable, potentially one per command (?)\n\n- start with git-clean. It's well defined which files are cleaned\n from a repository when running the command. Add them to a commit on\n the tip of the current branch.\n\n Start a new branch (or use the existing one if applicable) in\n refs/restore/history, and add a commit including a notes file. The\n commit message contains the operation that was executed (clean in\n this case), and the hash of the commit we created which includes the\n cleaned files.\n\n Add a note to the commit, detailing from which command we come from,\n which files we added (not strictly necessary, as we can infer it\n from the parent commit).\n\n Useful in itself as the user can recover the files manually if\n needed, and can be sent as separate patch series.\n\n Potential problems: Git has no way to track directories. This can\n be mitigated by keeping the list of directories in the attached\n note.\n\n- add a git recover command. The command looks at This would look like `git recover\n `, where commit is the hash of the commit we saved before.\n\n This works by reading the note attached to the commit, figuring out\n which command was run before, and restoring the state we were in\n before.\n\n Potential problems: conflicts, but I think this can be solved by\n simply erroring out, at least in the first iteration.\n\n- the next command could be git mv -f, git reset -f and friends. It\n gets more tricky here, as we'll have to deal with the state of the\n files in the index.\n\n Analogous to git clean, the changes in the working tree are all\n staged and added to a new commit on the tip of the current branch.\n\n The note on this commit needs to contain the necessary data to\n rebuild the state in the index. The format is more closely\n specified below. We also need the corresponding changes in the\n git restore command.\n\n Restored files will be written to disk as racily smudged, so the\n contents are checked by git, as we lost the meta-data anyway. This\n comes at a slight performance impact, but I think that's okay as we\n potentially saved the user a lot of time re-doing all the changes.\n\n- git branch/tag --force. Store the name and the old location of the\n branch in refs/restore/history. There are no files lost with this\n operation, so no additional commits as for git clean or git reset\n etc. are needed. The format of the commit depends on the exact\n operation that was forced, for exact format see below.\n\nThis treatment can't make all operations safe. Any operation that\ntouches the remote is hard to undo as some users already might have\nfetched the new state of the remote (e.g. git push -f). Others such\nas git-gc will inevitably delete information from the disk, but\nchanging that\n\nThere's more, but I don't think just writing up all commands without\nany code would make any sense.\n\nFormats:\n- commits in refs/restore/history:\nempty commits with the following commit message format for git-clean\nand git-reset and friends:\n$versionnumber\\n\n$command\\n\n$branchname\\n\n$sha1ofreferencedcommit\\n\n\nempty commits with the following commit message format for git branch\nand friends\n$versionnumber\\n\n$command\\n (this includes the exact operation that was forced\n(e.g. move, delete etc.)\n$branchname\\n\n$sha1ThatWasReferencedByTheBranch\\n\n$overwrittenbranchname\\n (this and the sha1 below are only used for\n--move)\n$sha1ReferencedByOverwrittenBranch\\n\n\n- notes file: The format can be different for different commands, as\n they all have different needs\n\n - git clean:\n list of affected files and directories separated by '\\0'.\n I think we could get away with only the directories, but adding\n the filenames as well might make the recovery part simpler.\n\n - git reset, etc.:\n the following info is stored for each file that is modified by the\n original command.\n\n 32-bit signature\n 32-bit number of index entries\n 32-bit mode (object type + unix permissions)\n 160-bit SHA-1\n 16-bit flags (extra careful here what we want to do with the\n assume valid flag)\n path name (variable length)\n\n resolve-undo extension (same format as in the index)\n\nAlternatives:\n- Have a history for each branch in refs/restore/$branchname.\n * Advantages:\n Each branch has its own history, which can lead to fewer conflicts\n when restoring (e.g. user uses `git reset --hard` on one branch,\n switches to another branch works (potentially adds more stuff to\n this branch), later goes back to the old branch and discovers `git\n reset --hard` was actually the wrong thing to do and would like\n the data back.\n * Disadvantages:\n It is harder for the user to intuitively know what git restore\n will do exactly.\n It's much more limited when we want to extend it to branch\n removals, etc.\n\n- Storing additional information in the refs/restore/history ref\n * Advantages:\n No need for extra notes\n * Disadvantages:\n Data doesn't get garbage collected without user interaction,\n potentially blowing up the repository size. Especially using `git\n clean`, where binary files might be involved.\n\n- Store the whole index in the note\n * Advantages:\n Simpler way of restoring the index (including all of the\n extensions)\n * Disadvantages:\n Need to take care of both the index and the split index.\n Will consume a lot more disk space in the normal case (only a few\n of the files in the repository are changed, while the majority\n remains unchanged).\n\n- Store the changed files in refs/restore/history instead of a new\n commit on the tip of the current branch.\n * Advantages:\n All the information is in one place.\n Data will not be garbage collected.\n * Disadvantages:\n Data will not be garbage collected. (Repository size is probably\n going to blow up after a while)\n It takes more effort to find the parent and diff against it.\n"},{"id":"278666","messageId":"vpqr3g827cu.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"0E364888-DD95-4B47-9679-3CB586FC7E8C@gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-19T12:49:05Z","receivedAt":"2016-02-19T12:49:05Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Lars Schneider writes:\n\n> Thanks for your elaborate response. I think I got your point and I\n> tried to adjust my \"beginner mode\" proposal accordingly [1].\n\nNow merged as\nhttps://github.com/git/git.github.io/commit/6b8b5e19cdb221192dedd70ba3e207636f1cdab1\n\nI've added a warning for students:\n\n Note that this project is not technically difficult, it requires a\n deep understanding of Git: how each command is meant to be used, what\n are the potential dangers, ... Reaching a solution that effectively\n protects beginners without harming anyone is much harder than it\n seems. See for example [this\n thread](http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286614)\n for example potential objections. If chosen, this project should be\n discussed in depth on the list before and after the student\n application.\n\nI just want to avoid students loosing their time writting silly\nproposals (once you have seen what the majority of proposals looks like,\nnothing surprises you anymore ;-) ).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278700","messageId":"xmqq8u2gcubh.fsf@gitster.mtv.corp.google.com","threadId":"41380","inReplyTo":"vpqr3g96tn6.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-19T20:35:14Z","receivedAt":"2016-02-19T20:35:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n>> We have these \"powerful\" tools for a reason. After making a mess\n>> experimenting with your working tree files, \"reset --hard\" is the\n>> best tool to go back to the known-good state,\n>\n> I disagree with that. This reminds me a discussion I had with a student\n> a few years ago:\n>\n> student: how do a clear all changes from my worktree?\n> me: git reset --hard\n>\n> the next day:\n>\n> student: OK, now, how do I get my changes back?\n> me: ...!\n>\n> There's almost no situation where reset --hard is the best tool.\n\nI obviously have to disagree. After maknig a mess experimenting,\nwhen you want to discard all that, \"reset --hard\" is the best\ntool--the situation of your student may be quite different but you\ndidn't make it clear what s/he wanted to salvage. In any case, I\nwasn't asking about \"clear all changes for now, to be salvaged\nlater\".\n\nThe \"experimenting\" would include mergy operations like \"am -3\" and\n\"cherry-pick\". \"After queuing a topic and trying it in isolation,\nan attempt to merge to the baseline results in quite a mess, and I\ngive up\"--there is nothing to salvage.\n\nAnd obviously, \"stash\" is not useful in such a situation. You could\nuse \"tar cf ../saved .\", though.\n\n> Now, another issue with the proposed core.isbeginner is compatibility\n> with scripts. \n\nYes.\n\n> Dangerous commands are often plumbing, and a beginner may\n> still want to use scripts or other porcelain on top of it. Typically, I\n> think this rules out \"git reset --hard\" which is legitimate in scripts.\n\nI agree that an \"under core.isbeginner, the command will always be\nrefused\" change can be written without thinking and it will be\nuseless for anything that has ledigimate uses (like, but not limited\nto, being used in scripts) [*1*].\n\nBut not so fast.\n\nIf you can figure out when \"git reset --hard\" is legitimate based\n*NOT* only on the fact that it is driven by a script, but on what\nkind of modifications to the working tree contents, the index\ncontents and the refs are about to be made by the command, then\n\"core.isbeginner\" can be a permission for the command to spend extra\ncycles to examine the situation carefully to decide to selectively\ngo ahead, warn and go ahead, or refuse.\n\nThat of course takes a real thinking. \n\n\n[Footnote]\n\n*1* I'd refuse to take a patch to make scripted Porcelains that make\nlegit calls to \"powerful\" tools export GIT_SCRIPT_IS_RUNNING_YOU\nenvironment variable as a workaround for such a kludge.\n"},{"id":"278701","messageId":"xmqq4md4cu83.fsf@gitster.mtv.corp.google.com","threadId":"41380","inReplyTo":"0E364888-DD95-4B47-9679-3CB586FC7E8C@gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-19T20:37:16Z","receivedAt":"2016-02-19T20:37:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider writes:\n\n> If this mode is enabled then Git shall print a warning message before \n> running a potentially destructive command. In addition to the warning \n> Git shall print a command that would reverse the operation if possible. \n> Most of the information to reverse an operation is already available \n> via git reflog. However, the task here is to make this information more \n> easily accessible to Git beginners.\n>\n> --\n>\n> Does this go into the direction of \"making the powerful tool harder to\n> misuse\"?\n\nNot really, if done without a real thinking. The approach risks to\nmake the powerful tool harder to use, not just misuse.\n"},{"id":"278728","messageId":"alpine.DEB.1.00.1602201027170.20796@bonsai2","threadId":"41380","inReplyTo":"xmqq8u2gcubh.fsf@gitster.mtv.corp.google.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-02-20T09:28:46Z","receivedAt":"2016-02-20T09:28:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Fri, 19 Feb 2016, Junio C Hamano wrote:\n\n> The \"experimenting\" would include mergy operations like \"am -3\" and\n> \"cherry-pick\". \"After queuing a topic and trying it in isolation, an\n> attempt to merge to the baseline results in quite a mess, and I give\n> up\"--there is nothing to salvage.\n> \n> And obviously, \"stash\" is not useful in such a situation.\n\nI think this is more a short-coming of \"stash\" than anything else.\n\nMany a times did I wish I could simply quickly stash a failed merge and\nthen come back later. Or not. Just like stashed changes without conflicts\nallow me to do already.\n\nCiao,\nDscho\n"},{"id":"278850","messageId":"CACsJy8BzkWSc11ODenEuGBBta+dkLS893o7oRS57_ctoB5ie8A@mail.gmail.com","threadId":"41380","inReplyTo":"vpqd1s04zzs.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-22T09:28:32Z","receivedAt":"2016-02-22T09:28:32Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Feb 13, 2016 at 6:21 PM, Matthieu Moy\n wrote:\n> Less urgent, but we need to add more stuff to be credible:\n>\n> ...\n>\n> http://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/.\n> I think most projects are not valid anymore, and we need new ones.\n>\n> To all: please contribute to these pages, either by sending patches here\n> (CC: me and peff), pushing directly if you have access, or submitting\n> pull-requests. The repo is https://github.com/git/git.github.io/.\n\nIdea for microprojects. If you compile using gcc with -Wshadow, it\nspots local variables that shadow another local or global variables.\nThese are usually bad because it makes it's easy to make mistakes when\nchanging the code.\n\n_If_ you agree shadow vars are bad and should be exterminated,\n'master' has 94 warnings spreading over 49 files. A student can pick\n_one_ file and try to fix all warnings in that file. There are many\npossible approaches (rename, combine vars, change scope, even\nrestructure/kill global vars..), plenty of room for discussion.\n-- \nDuy\n"},{"id":"278855","messageId":"vpqziutkps7.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"CACsJy8BzkWSc11ODenEuGBBta+dkLS893o7oRS57_ctoB5ie8A@mail.gmail.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-22T10:22:48Z","receivedAt":"2016-02-22T10:22:48Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Duy Nguyen writes:\n\n> On Sat, Feb 13, 2016 at 6:21 PM, Matthieu Moy\n> wrote:\n>> Less urgent, but we need to add more stuff to be credible:\n>>\n>> ...\n>>\n>> http://git.github.io/SoC-2016-Microprojects/ => I just did s/2015/2016/.\n>> I think most projects are not valid anymore, and we need new ones.\n>>\n>> To all: please contribute to these pages, either by sending patches here\n>> (CC: me and peff), pushing directly if you have access, or submitting\n>> pull-requests. The repo is https://github.com/git/git.github.io/.\n>\n> Idea for microprojects. If you compile using gcc with -Wshadow, it\n> spots local variables that shadow another local or global variables.\n> These are usually bad because it makes it's easy to make mistakes when\n> changing the code.\n\nI hade a look an a few instances of the warning, and all of them were\nbad (sometimes even suspicious, I wouldn't be surprised if we found real\nbugs hunting these down).\n\n> _If_ you agree shadow vars are bad and should be exterminated,\n> 'master' has 94 warnings spreading over 49 files. A student can pick\n> _one_ file and try to fix all warnings in that file. There are many\n> possible approaches (rename, combine vars, change scope, even\n> restructure/kill global vars..), plenty of room for discussion.\n\n+1.\n\nAre there counter-arguments to this?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"278906","messageId":"20160222214246.GE15595@sigill.intra.peff.net","threadId":"41380","inReplyTo":"vpqziutkps7.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-22T21:42:46Z","receivedAt":"2016-02-22T21:42:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 22, 2016 at 11:22:48AM +0100, Matthieu Moy wrote:\n\n> > Idea for microprojects. If you compile using gcc with -Wshadow, it\n> > spots local variables that shadow another local or global variables.\n> > These are usually bad because it makes it's easy to make mistakes when\n> > changing the code.\n> \n> I hade a look an a few instances of the warning, and all of them were\n> bad (sometimes even suspicious, I wouldn't be surprised if we found real\n> bugs hunting these down).\n\nI looked at a handful, too, and many looked fine (e.g., shadowing an\noverly-broadly-named global parameter with a function parameter). Not\nthat I'm against squelching them. There's definitely potential for\nconfusion, and I won't be surprised either if there's a real bug lurking\nin there (which we can't find because of the number of false positives).\n\nBut...\n\n> > _If_ you agree shadow vars are bad and should be exterminated,\n> > 'master' has 94 warnings spreading over 49 files. A student can pick\n> > _one_ file and try to fix all warnings in that file. There are many\n> > possible approaches (rename, combine vars, change scope, even\n> > restructure/kill global vars..), plenty of room for discussion.\n> \n> +1.\n> \n> Are there counter-arguments to this?\n\nI agree that there are a lot of different ways to resolve each instance,\nand it will vary from case to case. I think the original point of a\nmicroproject was to do something really easy and not contentious, so\nthat the student could get familiar with all of the other parts of the\ncycle: writing a commit message, formatting the patch, posting to the\nlist, etc.\n\nIt seems like this has a high chance of frustrating students as they get\nembroiled in back-and-forth review. I dunno. Maybe it should be marked\nwith a star as a \"challenge\" microproject. :)\n\n-Peff\n"},{"id":"278907","messageId":"xmqqlh6c5ryz.fsf@gitster.mtv.corp.google.com","threadId":"41380","inReplyTo":"20160222214246.GE15595@sigill.intra.peff.net","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-22T21:56:52Z","receivedAt":"2016-02-22T21:56:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I agree that there are a lot of different ways to resolve each instance,\n> and it will vary from case to case. I think the original point of a\n> microproject was to do something really easy and not contentious, so\n> that the student could get familiar with all of the other parts of the\n> cycle: writing a commit message, formatting the patch, posting to the\n> list, etc.\n\nI had an impression that Micros are also used as an aptitude test,\nand one important trait we want to see in a potential developer is\nhow well s/he interacts with others in such a discussion. So \"easy\nand not contentious\" might not be a very good criteria.\n\nI dunno.\n\n> It seems like this has a high chance of frustrating students as they get\n> embroiled in back-and-forth review. I dunno. Maybe it should be marked\n> with a star as a \"challenge\" microproject. :)\n"},{"id":"278908","messageId":"20160222220248.GC18250@sigill.intra.peff.net","threadId":"41380","inReplyTo":"xmqqlh6c5ryz.fsf@gitster.mtv.corp.google.com","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-22T22:02:48Z","receivedAt":"2016-02-22T22:02:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 22, 2016 at 01:56:52PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I agree that there are a lot of different ways to resolve each instance,\n> > and it will vary from case to case. I think the original point of a\n> > microproject was to do something really easy and not contentious, so\n> > that the student could get familiar with all of the other parts of the\n> > cycle: writing a commit message, formatting the patch, posting to the\n> > list, etc.\n> \n> I had an impression that Micros are also used as an aptitude test,\n> and one important trait we want to see in a potential developer is\n> how well s/he interacts with others in such a discussion. So \"easy\n> and not contentious\" might not be a very good criteria.\n> \n> I dunno.\n\nI sort-of agree. I think of the microprojects as more of a \"fizz-buzz\",\nwhere you intentionally keep the technical level very low so that you\ncan evaluate the other things.\n\nSo I think a little back and forth is good; almost everybody does\nsomething a little wrong in their first patch submission. But I'd worry\nabout a topic that is going to involve a lot of bikeshedding or subtle\nnuances to finding the correct solution. I certainly think _some_\ncandidates can handle that, but for the ones who cannot, it may\nfrustrate all involved.\n\n-Peff\n"},{"id":"279001","messageId":"vpqr3g3h8n5.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"20160222220248.GC18250@sigill.intra.peff.net","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-23T13:13:34Z","receivedAt":"2016-02-23T13:13:34Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> On Mon, Feb 22, 2016 at 01:56:52PM -0800, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>> \n>> > I agree that there are a lot of different ways to resolve each instance,\n>> > and it will vary from case to case. I think the original point of a\n>> > microproject was to do something really easy and not contentious, so\n>> > that the student could get familiar with all of the other parts of the\n>> > cycle: writing a commit message, formatting the patch, posting to the\n>> > list, etc.\n>> \n>> I had an impression that Micros are also used as an aptitude test,\n>> and one important trait we want to see in a potential developer is\n>> how well s/he interacts with others in such a discussion. So \"easy\n>> and not contentious\" might not be a very good criteria.\n>> \n>> I dunno.\n>\n> I sort-of agree. I think of the microprojects as more of a \"fizz-buzz\",\n> where you intentionally keep the technical level very low so that you\n> can evaluate the other things.\n\nI agree with \"very low\", but I don't think we should eliminate\ncompletely the difficulty. During the selection, microprojects can be\nvery efficient in eliminating the really bad candidates (usually, there\nare quite a few), but once the first selection is done, we still need\ntools to separate \"moderately good\" and \"really good\" candidates.\n\n> So I think a little back and forth is good; almost everybody does\n> something a little wrong in their first patch submission. But I'd worry\n> about a topic that is going to involve a lot of bikeshedding or subtle\n> nuances to finding the correct solution. I certainly think _some_\n> candidates can handle that, but for the ones who cannot, it may\n> frustrate all involved.\n\nWell, starting a microproject and realizing afterwards that it was a\nhard one is frustrating. But picking a very easy project and see someone\nelse do a brillant job on a harder one, and this someone else get\naccepted is also frustrating.\n\nI don't think this \"kill -Wshadow warning\" is really too hard. I'd say\nit's hard enough to be interesting for students who have a chance to be\nselected in the end.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"279146","messageId":"20160224105249.GC20807@sigill.intra.peff.net","threadId":"41380","inReplyTo":"vpqr3g3h8n5.fsf@anie.imag.fr","subject":"Re: GSoC 2016: applications open, deadline = Fri, 19/2","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-24T10:52:49Z","receivedAt":"2016-02-24T10:52:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 23, 2016 at 02:13:34PM +0100, Matthieu Moy wrote:\n\n> > So I think a little back and forth is good; almost everybody does\n> > something a little wrong in their first patch submission. But I'd worry\n> > about a topic that is going to involve a lot of bikeshedding or subtle\n> > nuances to finding the correct solution. I certainly think _some_\n> > candidates can handle that, but for the ones who cannot, it may\n> > frustrate all involved.\n> \n> Well, starting a microproject and realizing afterwards that it was a\n> hard one is frustrating. But picking a very easy project and see someone\n> else do a brillant job on a harder one, and this someone else get\n> accepted is also frustrating.\n\nMy \"all involved\" also included reviewers and list regulars. :)\n\n> I don't think this \"kill -Wshadow warning\" is really too hard. I'd say\n> it's hard enough to be interesting for students who have a chance to be\n> selected in the end.\n\nFair enough. If you want to add it, go for it. The worst that can happen\nis some failed microprojects.\n\n-Peff\n"},{"id":"279842","messageId":"vpq4mcr8c3j.fsf_-_@anie.imag.fr","threadId":"41380","inReplyTo":"1455875178.343346.31.camel@dwim.me","subject":"Git has been accepted as a GSoC 2016 mentor organization!","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-29T21:01:52Z","receivedAt":"2016-02-29T21:01:52Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Hi,\n\nThis is my pleasure to inform you all that Git has just been accepted as\na GSoC mentor organization.\n\n https://summerofcode.withgoogle.com/organizations/?sp-page=3\n\nI've invited Johannes, Stefan, Christian and Lars as potential mentors\nfor Git, and Carlos to represent libgit2. I also took the freedom to\ninvite Junio, not really as potential mentor, but to give access to\nstudents proposals and give an opportunity to comment.\n\nLet me (or Peff) know if you want an invitation too. No commitment to\nmentor anyone for now if you accept the invitation, this will be decided\nlater.\n\nAs a reminder, we post all the GSoC related stuff here:\n\n http://git.github.io/SoC-2016-Ideas/\n http://git.github.io/SoC-2016-Microprojects/\n\nCheers!\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"280389","messageId":"20160308224625.GA29922@sigill.intra.peff.net","threadId":"41380","inReplyTo":"vpq4mcr8c3j.fsf_-_@anie.imag.fr","subject":"Re: Git has been accepted as a GSoC 2016 mentor organization!","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-03-08T22:46:26Z","receivedAt":"2016-03-08T22:46:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 29, 2016 at 10:01:52PM +0100, Matthieu Moy wrote:\n\n> Hi,\n> \n> This is my pleasure to inform you all that Git has just been accepted as\n> a GSoC mentor organization.\n> \n> https://summerofcode.withgoogle.com/organizations/?sp-page=3\n> \n> I've invited Johannes, Stefan, Christian and Lars as potential mentors\n> for Git, and Carlos to represent libgit2. I also took the freedom to\n> invite Junio, not really as potential mentor, but to give access to\n> students proposals and give an opportunity to comment.\n> \n> Let me (or Peff) know if you want an invitation too. No commitment to\n> mentor anyone for now if you accept the invitation, this will be decided\n> later.\n> \n> As a reminder, we post all the GSoC related stuff here:\n> \n> http://git.github.io/SoC-2016-Ideas/\n> http://git.github.io/SoC-2016-Microprojects/\n\nI've also signed us up for Outreachy, which is an internship program\ndesigned to encourage open source participation by under-represented\ngroups. Details are here:\n\n https://www.gnome.org/outreachy/\n\nbut I'll try to summarize here what it means for us.\n\nIt's similar to GSoC and runs during the same time frame. It's open to\nnon-students (so some people who could not do GSoC can apply), but\napplications must be from one of the under-represented groups listed at\nthe link above. People can apply to both if they are eligible, but can\nonly be accepted to one. As Outreachy is advertised in certain circles\nwhere GSoC is not (or where people might be intimidated by GSoC), my\nhope is we can drive some more diversity in GSoC applicants (not to\nmention catching people who don't qualify for GSoC because they aren't\nfollowing traditional education paths).\n\nThe catch is that Outreachy doesn't provide the stipend money; the\nprojects have to find their own funding. I don't think this should be a\nbig problem for Git. I have some leads we can follow if we get an\nOutreachy intern (and obviously if they are accepted through GSoC, it's\na non-issue).\n\nI've put up a landing page for our participation here:\n\n http://git.github.io/Outreachy-2016-May/\n\nComments/patches welcome.\n\nMost of the resources are just pointers to our GSoC stuff. This does\nmean I've effectively signed our mentors up to participate in this\nprogram. I hope that's OK, as it's effectively the same commitment as\nGSoC (and obviously we would spread our mentoring resources over the\ntotal pool of applicants between both programs, and not double-book any\nmentors).\n\nAnd finally, I'm sorry to spring this on the list as a fait accompli.\nOne of the leaders of Outreachy contacted me, Junio, and Shawn off-list\nasking if we'd like to participate. We agreed it sounded reasonable, but\nwe have to move reasonably quickly, as the application period has\nalready begun (it runs until March 22). That's why I've taken the\ninitial steps independently. But if anybody has comments, or is\nviolently opposed, please don't take my actions as an attempt to skip\nthe discussion phase. :)\n\n-Peff\n"},{"id":"280390","messageId":"xmqqmvq8k204.fsf@gitster.mtv.corp.google.com","threadId":"41380","inReplyTo":"20160308224625.GA29922@sigill.intra.peff.net","subject":"Re: Git has been accepted as a GSoC 2016 mentor organization!","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-08T23:01:47Z","receivedAt":"2016-03-08T23:01:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I've also signed us up for Outreachy, which is an internship program\n> designed to encourage open source participation by under-represented\n> groups. Details are here:\n>\n> https://www.gnome.org/outreachy/\n>\n> but I'll try to summarize here what it means for us.\n\nhttps://wiki.gnome.org/Outreachy/2016/MayAugust#Participating_Organizations\n\ndoes not seem to list us though. Is that expected?\n"},{"id":"280392","messageId":"20160308230352.GA30641@sigill.intra.peff.net","threadId":"41380","inReplyTo":"xmqqmvq8k204.fsf@gitster.mtv.corp.google.com","subject":"Re: Git has been accepted as a GSoC 2016 mentor organization!","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-03-08T23:03:52Z","receivedAt":"2016-03-08T23:03:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 08, 2016 at 03:01:47PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I've also signed us up for Outreachy, which is an internship program\n> > designed to encourage open source participation by under-represented\n> > groups. Details are here:\n> >\n> > https://www.gnome.org/outreachy/\n> >\n> > but I'll try to summarize here what it means for us.\n> \n> https://wiki.gnome.org/Outreachy/2016/MayAugust#Participating_Organizations\n> \n> does not seem to list us though. Is that expected?\n\nYes. I _just_ sent an email to the organizers telling them our landing\npage was up (though I think we can add ourselves, too).\n\n-Peff\n"},{"id":"280412","messageId":"vpq8u1sht6z.fsf@anie.imag.fr","threadId":"41380","inReplyTo":"20160308224625.GA29922@sigill.intra.peff.net","subject":"Re: Git has been accepted as a GSoC 2016 mentor organization!","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-03-09T09:55:00Z","receivedAt":"2016-03-09T09:55:00Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> I've also signed us up for Outreachy, which is an internship program\n> designed to encourage open source participation by under-represented\n> groups.\n\nGood. In the case of the Git community, \"under-represented\" may even be\na euphemism as it is now :-\\.\n\n> Most of the resources are just pointers to our GSoC stuff. This does\n> mean I've effectively signed our mentors up to participate in this\n> program. I hope that's OK,\n\nNot sure whether I was supposed to receive something, but I did not.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"280418","messageId":"alpine.DEB.2.20.1603091348280.4690@virtualbox","threadId":"41380","inReplyTo":"20160308224625.GA29922@sigill.intra.peff.net","subject":"Re: Git has been accepted as a GSoC 2016 mentor organization!","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-03-09T13:50:45Z","receivedAt":"2016-03-09T13:50:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Tue, 8 Mar 2016, Jeff King wrote:\n\n> I've effectively signed our mentors up to participate in this program.\n> I hope that's OK\n\nSpeaking for myself, I think this is more than just okay. I really like\nthe idea of more diversity in the Git community.\n\nCiao,\nDscho\n"},{"id":"280419","messageId":"20160309140826.GA3642@sigill.intra.peff.net","threadId":"41380","inReplyTo":"vpq8u1sht6z.fsf@anie.imag.fr","subject":"Re: Git has been accepted as a GSoC 2016 mentor organization!","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-03-09T14:08:26Z","receivedAt":"2016-03-09T14:08:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 09, 2016 at 10:55:00AM +0100, Matthieu Moy wrote:\n\n> > Most of the resources are just pointers to our GSoC stuff. This does\n> > mean I've effectively signed our mentors up to participate in this\n> > program. I hope that's OK,\n> \n> Not sure whether I was supposed to receive something, but I did not.\n\nNo, you shouldn't have gotten anything yet. I only meant that since I am\npointing Outreachy applicants to the GSoC ideas page, people who signed\nup to mentor GSoC may effectively be called on to mentor for Outreachy\ninstead.\n\nIt's basically the same commitment, which is why I was comfortable doing\nit without asking beforehand (but again, please speak up if you don't\nagree).\n\n-Peff\n"},{"id":"280504","messageId":"20160309193415.GA6408@sigill.intra.peff.net","threadId":"41380","inReplyTo":"20160308224625.GA29922@sigill.intra.peff.net","subject":"Re: Git has been accepted as a GSoC 2016 mentor organization!","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-03-09T19:34:15Z","receivedAt":"2016-03-09T19:34:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 08, 2016 at 05:46:25PM -0500, Jeff King wrote:\n\n> Most of the resources are just pointers to our GSoC stuff. This does\n> mean I've effectively signed our mentors up to participate in this\n> program. I hope that's OK, as it's effectively the same commitment as\n> GSoC (and obviously we would spread our mentoring resources over the\n> total pool of applicants between both programs, and not double-book any\n> mentors).\n\nActually, there is one thing we should do. :)\n\nOur ideas page is missing potential mentors for many of the projects.\nThis is useful information for coordinating GSoC, but I think is doubly\nimportant for Outreachy, where applicants are encouraged to get in touch\nwith mentors early.\n\nSo would people who have proposed ideas mind going over the page at\n\n http://git.github.io/SoC-2016-Ideas/\n\nand making sure they are listed under their projects? And likewise, can\npeople make sure they are listed with their preferred email addresses? I\ndo think we generally expect people to communicate on the list, but it\nshould be as easy as possible for them to cc the mentors.\n\nIf you have fixes to make, please feel free to push straight to \"master\"\nof that repository (if you have access), or open a pull request or send\nme a patch if you don't.\n\n-Peff\n"}]}