{"thread":{"id":"35953","subject":"Git in GSoC 2014","startedAt":"2014-02-25T15:41:59Z","lastAt":"2014-04-22T02:18:46Z","messageCount":20,"participants":["Jeff King","Dmitry S. Dolzhenko","Michael Haggerty","Duy Nguyen","Vicent Martí","Shawn Pearce","Torsten Bögershausen","Junio C Hamano","Andrew Ardill","Brian Gesiak"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"235325","messageId":"20140225154158.GA9038@sigill.intra.peff.net","threadId":"35953","inReplyTo":null,"subject":"Git in GSoC 2014","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-25T15:41:59Z","receivedAt":"2014-02-25T15:41:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"I'm pleased to announce that Git has been accepted to this year's Google\nSummer of Code.\n\nStudent proposals will start coming in on March 22. In the meantime\nstudents will be reading our Ideas page[1] and enquiring about the\nprogram on the mailing list and on irc. There are many ways that\nexisting git developers can help:\n\n - continue to add to and polish the Ideas page\n\n - interact with prospective students; besides responding to questions\n on the list, hanging around on #git and #git-devel on freenode is\n helpful\n\n - volunteer to mentor and/or rank student proposals. You can sign up\n at http://google-melange.com, and request to be added as a mentor\n for the git project.\n\nWe didn't discuss earlier whether we would have any specific\nrequirements for students during the proposal period (e.g., having a\npatch accepted). It would be good to put together rules (or barring any\nspecific requirements, guidelines to help students put together a good\nproposal) as soon as possible. Suggestions are welcome.\n\n-Peff\n\n[1] http://git.github.io/SoC-2014-Ideas.html\n"},{"id":"235326","messageId":"530CC805.1060708@yandex.ru","threadId":"35953","inReplyTo":"20140225154158.GA9038@sigill.intra.peff.net","subject":"Re: Git in GSoC 2014","fromName":"Dmitry S. Dolzhenko","fromEmail":"dmitrys.dolzhenko@yandex.ru","sentAt":"2014-02-25T16:42:45Z","receivedAt":"2014-02-25T16:42:45Z","isPatch":false,"sender":{"key":"dmitrys.dolzhenko@yandex.ru","avatar":null},"body":"Hi.\n\nI was just going to write an email about that I would like to \nparticipate in GSoC and contribute to Git project.\n\nI don't have wide experience in C programming, but I could be start as a \n\"janitor\". I found several tasks here \nhttps://git.wiki.kernel.org/index.php/Janitor. For example \"Refactor \nbinary search functions\". If this task is actual, I could be to start \nfrom it.\n"},{"id":"235327","messageId":"530CCFB0.5050406@alum.mit.edu","threadId":"35953","inReplyTo":"20140225154158.GA9038@sigill.intra.peff.net","subject":"Re: Git in GSoC 2014","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-02-25T17:15:28Z","receivedAt":"2014-02-25T17:15:28Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/25/2014 04:41 PM, Jeff King wrote:\n> I'm pleased to announce that Git has been accepted to this year's Google\n> Summer of Code.\n\nCool! Thanks to Peff and Thomas and Vicent and whomever else was\ninvolved in getting our application done! For those who don't know, the\napplication covers both Git core and libgit2.\n\n> We didn't discuss earlier whether we would have any specific\n> requirements for students during the proposal period (e.g., having a\n> patch accepted). It would be good to put together rules (or barring any\n> specific requirements, guidelines to help students put together a good\n> proposal) as soon as possible. Suggestions are welcome.\n\nRequiring students to submit a reasonable patch and follow up on review\ncomments seems like it would be a good way to filter out non-serious\nstudents. (I hesitate to require that the patch be accepted because it\ncan take quite a while for a patch to make it to master, despite of the\nstudent's efforts.)\n\nDoes anybody know whether other organizations have had good experience\nwith criteria like that? Does it chase *all* the applicants away?\n\nIf we wanted to impose such a hurdle, then we would definitely have to\nmake up a list of microprojects so that the students don't have to start\nfrom nothing. I imagine it shouldn't be too hard to find tiny projects\nestimated at 10-30 minutes of actual work, which should be plenty\ndifficult for a student who also has to figure out how to check out the\ncode, conform to our coding standards, run the unit tests, create a\npatch submission, etc.\n\nIf the reaction is positive to this idea then I volunteer to spend\nseveral hours tomorrow looking for microprojects, and I suggest other\ncore developers do so as well. They should presumably be submitted as\npatches to the ideas repository [1].\n\nWhat do you think?\n\nMichael\n\n[1] https://github.com/git/git.github.io\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235360","messageId":"20140226102350.GB25711@sigill.intra.peff.net","threadId":"35953","inReplyTo":"530CCFB0.5050406@alum.mit.edu","subject":"Re: Git in GSoC 2014","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-26T10:23:50Z","receivedAt":"2014-02-26T10:23:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 25, 2014 at 06:15:28PM +0100, Michael Haggerty wrote:\n\n> > We didn't discuss earlier whether we would have any specific\n> > requirements for students during the proposal period (e.g., having a\n> > patch accepted). It would be good to put together rules (or barring any\n> > specific requirements, guidelines to help students put together a good\n> > proposal) as soon as possible. Suggestions are welcome.\n> \n> Requiring students to submit a reasonable patch and follow up on review\n> comments seems like it would be a good way to filter out non-serious\n> students. (I hesitate to require that the patch be accepted because it\n> can take quite a while for a patch to make it to master, despite of the\n> student's efforts.)\n\nYeah, I think the early stages of \"accepted\" are somewhat vague.\nProbably \"patch is in next\" is a reasonable definition, but I do not\nthink we even need to bind ourselves so strictly. Humans read, evaluate,\nand rank the proposals, so we can use our judgement about whether a\npatch looks promising.\n\n> Does anybody know whether other organizations have had good experience\n> with criteria like that? Does it chase *all* the applicants away?\n\nIf you haven't seen it, there is a guide written by mentors and admins\nfrom past years:\n\n http://en.flossmanuals.net/GSoCMentoring/\n\nI did not see this particular subject covered, though I seem to recall\nit has come up on the mentor list in past years. I can't search the\narchive now, because they haven't re-added me for this year yet, but\nI'll do so once I have access.\n\nI think I'm in favor. It seems like a minimal hurdle to overcome, and I\nthink everybody is more than happy to coach new contributors through the\nprocess.\n\n> If we wanted to impose such a hurdle, then we would definitely have to\n> make up a list of microprojects so that the students don't have to start\n> from nothing. I imagine it shouldn't be too hard to find tiny projects\n> estimated at 10-30 minutes of actual work, which should be plenty\n> difficult for a student who also has to figure out how to check out the\n> code, conform to our coding standards, run the unit tests, create a\n> patch submission, etc.\n\nThe hack-a-thon bug list I posted earlier has some potential points of\ninterest, but I need to update it to reflect the work done that day (a\nlot of that is trickling in to me for initial comments, and then I'll\ndirect them to the list, but I'm a bit behind on dealing with it).\n\n> If the reaction is positive to this idea then I volunteer to spend\n> several hours tomorrow looking for microprojects, and I suggest other\n> core developers do so as well. They should presumably be submitted as\n> patches to the ideas repository [1].\n\nYes, though I think it makes sense to put them on a separate page. We\nshould probably write up some notes for students, too: how to get in\ntouch with us, what do we expect of them in the pre-proposal period,\nwhat would we expect in terms of communication and day-to-day workflow\nduring the summer, etc.\n\n-Peff\n"},{"id":"235362","messageId":"530DC4D1.4060301@alum.mit.edu","threadId":"35953","inReplyTo":"20140226102350.GB25711@sigill.intra.peff.net","subject":"Re: Git in GSoC 2014","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-02-26T10:41:21Z","receivedAt":"2014-02-26T10:41:21Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/26/2014 11:23 AM, Jeff King wrote:\n> On Tue, Feb 25, 2014 at 06:15:28PM +0100, Michael Haggerty wrote:\n>> Requiring students to submit a reasonable patch and follow up on review\n>> comments seems like it would be a good way to filter out non-serious\n>> students. (I hesitate to require that the patch be accepted because it\n>> can take quite a while for a patch to make it to master, despite of the\n>> student's efforts.)\n> \n> Yeah, I think the early stages of \"accepted\" are somewhat vague.\n> Probably \"patch is in next\" is a reasonable definition, but I do not\n> think we even need to bind ourselves so strictly. Humans read, evaluate,\n> and rank the proposals, so we can use our judgement about whether a\n> patch looks promising.\n\nAgreed.\n\n> [...]\n>> If we wanted to impose such a hurdle, then we would definitely have to\n>> make up a list of microprojects so that the students don't have to start\n>> from nothing. [...]\n>> If the reaction is positive to this idea then I volunteer to spend\n>> several hours tomorrow looking for microprojects, and I suggest other\n>> core developers do so as well. They should presumably be submitted as\n>> patches to the ideas repository [1].\n> \n> Yes, though I think it makes sense to put them on a separate page. We\n> should probably write up some notes for students, too: how to get in\n> touch with us, what do we expect of them in the pre-proposal period,\n> what would we expect in terms of communication and day-to-day workflow\n> during the summer, etc.\n\nSince time is short, I already started on this. I wrote a first draft\nof an introduction for the students. I also started looking for\nmicroprojects. I started going through our source files alphabetically,\nand have already found six suggestions by \"bundle.c\", so I don't think\nthere will be a problem finding enough tiny things to do.\n\nSee my branch on GitHub [1] or read the appended text below.\n\nI've been looking for *really* tiny projects. Feedback is welcome about\nwhether they are too trivial to be meaningful in distinguishing\npromising students from no-hopers. My feeling is that there is so much\nprocess involved in submitting a patch that it will take even a\nwell-prepared student quite a while to make a change, no matter how trivial.\n\nAlso, how many suggested microprojects do you think we need (i.e., when\ncan I stop :-) )?\n\nMichael\n\n[1] https://github.com/mhagger/git.github.io/tree/microprojects\n\n\n---\nlayout: default\ntitle: SoC 2014 Applicant Microprojects\n---\n\n## Introduction\n\nIt is strongly recommended that students who want to apply to the Git\nproject for the Summer of Code 2014 should submit a small code-related\npatch to the Git project as part of their application. Think of these\nmicroprojects as the \"Hello, world\" of getting involved with the Git\nproject; the coding aspect of the change can be almost trivial, but to\nmake the change the student has to become familiar with many of the\npractical aspects of working on the Git project:\n\n* Downloading the source code: clone the repository using the\n [Git via Git](http://git-scm.com/downloads) instructions and read\n the `README` file.\n\n* Build the source code: this is described in the file `INSTALL`.\n\n* Glance over our coding guidelines in the file\n `Documentation/CodingGuidelines`. We take things like proper code\n formatting very seriously.\n\n* Read about the process for submitting patches to Git: this is\n described in `Documentation/SubmittingPatches`.\n\n* Making the actual change.\n\n* Run the test suite: this is described in the file `t/README`. (If\n you have added new functionality, you should also add tests, but\n most microprojects will not add new functionality.)\n\n* Commit your change. Surprise: we use Git for that, so you will need\n to gain at least\n [a basic familiarity](http://git-scm.com/documentation) with using\n Git. Make sure to write a good commit message that explains the\n reason for the change and any ramifications. Remember to add a\n Signed-off-by line (see the coding guidelines for more information).\n\n* Submit your change to the Git mailing list. For this step you\n probably want to use the commands `git format-patch` and `git\n send-email`.\n\n* Expect feedback, criticism, suggestions, etc. from the mailing list.\n\n *Respond to it!* and follow up with improved versions of your\n change. Even for a trivial patch you shouldn't be surprised if it\n takes two or more iterations before your patch is accepted. *This\n is the best part of the Git community; it is your chance to get\n personalized instruction from very experienced peers!*\n\nThe coding part of the microproject should be very small (say, 10-30\nminutes). We don't require that your patch be accepted into master by\nthe time of your formal application; we mostly want to see that you\nhave a basic level of competence and especially the ability to\ninteract with the other Git developers.\n\nWhen you submit your patch, please mention that you plan to apply for\nthe GSoC. This will ensure that we take special care not to overlook\nyour application among the large pile of others.\n\n## Ideas for microprojects\n\nThe following are just ideas. Any small code-related change would be\nsuitable. Just remember to keep the change small! It is much better\nto finish a small but complete patch than to try something too\nambitious and not get it done.\n\n1. Rewrite `git-compat-util.h:skip_prefix()` as a loop, so that it\n doesn't have to scan through the `prefix` string twice.\n\n2. Change `branch.c:install_branch_config()` to use `skip_prefix()`.\n\n3. In `branch.c:setup_tracking()`, figure out where the magic number\n `1024 - 7 - 7 - 1` comes from. (Looking through the commit\n history might help.) If the check involving the number is still\n necessary, document where the number comes from. If the check is\n no longer necessary, explain why and delete the check.\n\n4. Rewrite `bulk-checkin.c:finish_bulk_checkin()` to use a `strbuf`\n for handling `packname`, and explain why this is useful. Also\n check if the first argument of\n `pack-write.c:finish_tmp_packfile()` can be made const.\n\n5. Change `bundle.c:add_to_ref_list()` to use `hashcpy()`. See if\n you can find other places where `hashcpy()` should be used instead\n of `memcpy()`.\n\n6. Change `bundle.c:add_to_ref_list()` to use `ALLOC_GROW()`.\n\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235369","messageId":"20140226110433.GF25711@sigill.intra.peff.net","threadId":"35953","inReplyTo":"530DC4D1.4060301@alum.mit.edu","subject":"Re: Git in GSoC 2014","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-26T11:04:33Z","receivedAt":"2014-02-26T11:04:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 26, 2014 at 11:41:21AM +0100, Michael Haggerty wrote:\n\n> > Yes, though I think it makes sense to put them on a separate page. We\n> > should probably write up some notes for students, too: how to get in\n> > touch with us, what do we expect of them in the pre-proposal period,\n> > what would we expect in terms of communication and day-to-day workflow\n> > during the summer, etc.\n> \n> Since time is short, I already started on this. I wrote a first draft\n> of an introduction for the students. I also started looking for\n> microprojects. I started going through our source files alphabetically,\n> and have already found six suggestions by \"bundle.c\", so I don't think\n> there will be a problem finding enough tiny things to do.\n\nThanks, the intro text looks great.\n\nWe probably need some intro text to go on the ideas page (that is what\nGoogle links to for prospective students) that points them to the\nmicroproject page.\n\n> See my branch on GitHub [1] or read the appended text below.\n\nI've merged and pushed out your branch (I'll work on getting push access\nfor people, as there's no real reason for me to be an integration\nbottleneck with this stuff).\n\n> I've been looking for *really* tiny projects. Feedback is welcome about\n> whether they are too trivial to be meaningful in distinguishing\n> promising students from no-hopers. My feeling is that there is so much\n> process involved in submitting a patch that it will take even a\n> well-prepared student quite a while to make a change, no matter how trivial.\n\nI really like the level of the projects below. It should be more about\nthe process than the code, and I think you nailed that. I especially\nlike the ones that require some digging in history.\n\nThe bug list I mentioned before is probably too heavyweight in that\nsense (they're more like 4-6 hour projects for somebody who isn't\nfamiliar with the code, plus submission headaches on top of that).\n\n> Also, how many suggested microprojects do you think we need (i.e., when\n> can I stop :-) )?\n\nI think it depends on how quickly people do them. We can always add more\nif they run low (though 6 does not provide a huge buffer, so we may want\na few more).\n\n> 6. Change `bundle.c:add_to_ref_list()` to use `ALLOC_GROW()`.\n\nThis is the only one that seemed like it might be _too_ trivial to me.\nThe memcpy/hashcpy one is similarly trivial, but I like the add-on of\n\"look for other places\". I guess we could do that here, too.\n\n-Peff\n"},{"id":"235374","messageId":"CACsJy8Bw7JqokgGt46T7Xivk08F-DS4Dj-j1PWxoStu=cVzo5w@mail.gmail.com","threadId":"35953","inReplyTo":"20140225154158.GA9038@sigill.intra.peff.net","subject":"Re: Git in GSoC 2014","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-02-26T11:16:49Z","receivedAt":"2014-02-26T11:16:49Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 25, 2014 at 10:41 PM, Jeff King wrote:\n> I'm pleased to announce that Git has been accepted to this year's Google\n> Summer of Code.\n>\n> Student proposals will start coming in on March 22. In the meantime\n> students will be reading our Ideas page[1] and enquiring about the\n> program on the mailing list and on irc. There are many ways that\n> existing git developers can help:\n>\n> - continue to add to and polish the Ideas page\n\nOne thing I noticed after tg/index-v4-format is both libgit2 and jgit\ndo not seem to support index v4. So we could add \"index v4 support on\nlibgit2\" to the idea page. It's a relatively small task though once\nyou get a hang on index format.\n-- \nDuy\n"},{"id":"235375","messageId":"CAFFjANRqKqq_f9SCR4vP3YKUpfk1J2RQdB9G4gnY2OcZivzhXQ@mail.gmail.com","threadId":"35953","inReplyTo":"CACsJy8Bw7JqokgGt46T7Xivk08F-DS4Dj-j1PWxoStu=cVzo5w@mail.gmail.com","subject":"Re: Git in GSoC 2014","fromName":"Vicent Martí","fromEmail":"tanoku@gmail.com","sentAt":"2014-02-26T11:24:13Z","receivedAt":"2014-02-26T11:24:13Z","isPatch":false,"sender":{"key":"tanoku@gmail.com","avatar":"https://gravatar.com/avatar/271386991cb4c2b8f1e1ed1d059f3422cc3485de7a598f65043f70be021d095b?d=mp&s=160"},"body":"On Wed, Feb 26, 2014 at 12:16 PM, Duy Nguyen wrote:\n> On Tue, Feb 25, 2014 at 10:41 PM, Jeff King wrote:\n>> I'm pleased to announce that Git has been accepted to this year's Google\n>> Summer of Code.\n>>\n>> Student proposals will start coming in on March 22. In the meantime\n>> students will be reading our Ideas page[1] and enquiring about the\n>> program on the mailing list and on irc. There are many ways that\n>> existing git developers can help:\n>>\n>> - continue to add to and polish the Ideas page\n>\n> One thing I noticed after tg/index-v4-format is both libgit2 and jgit\n> do not seem to support index v4. So we could add \"index v4 support on\n> libgit2\" to the idea page. It's a relatively small task though once\n> you get a hang on index format.\n\nThat sounds like a nice task for the Summer of Code too, specially\nwith the current effort to make Index v4 more visible in Core Git.\n\nI wonder if anybody from JGit would also be interested on mentoring\nfor the equivalent task (index v4 on JGit). I've CC'ed Shawn Pearce.\n"},{"id":"235376","messageId":"CAFFjANTCU-OkydggYGy9tTJqx=TkWoVi2gJge4LUUkKcdB-eZQ@mail.gmail.com","threadId":"35953","inReplyTo":"530DC4D1.4060301@alum.mit.edu","subject":"Re: Git in GSoC 2014","fromName":"Vicent Martí","fromEmail":"tanoku@gmail.com","sentAt":"2014-02-26T11:25:36Z","receivedAt":"2014-02-26T11:25:36Z","isPatch":false,"sender":{"key":"tanoku@gmail.com","avatar":"https://gravatar.com/avatar/271386991cb4c2b8f1e1ed1d059f3422cc3485de7a598f65043f70be021d095b?d=mp&s=160"},"body":"On Wed, Feb 26, 2014 at 11:41 AM, Michael Haggerty wrote:\n> Since time is short, I already started on this. I wrote a first draft\n> of an introduction for the students. I also started looking for\n> microprojects. I started going through our source files alphabetically,\n> and have already found six suggestions by \"bundle.c\", so I don't think\n> there will be a problem finding enough tiny things to do.\n\nNote that for projects that are either libgit2-centric or mix Core Git\nand libgit2, it would be worth it to the students to submit a pull\nrequest on libgit2 (or ideally, on both projects, although that's\ngoing to be hard) in order to make themselves familiar with the code\nbase.\n"},{"id":"235377","messageId":"20140226112907.GA3599@sigill.intra.peff.net","threadId":"35953","inReplyTo":"CAFFjANTCU-OkydggYGy9tTJqx=TkWoVi2gJge4LUUkKcdB-eZQ@mail.gmail.com","subject":"Re: Git in GSoC 2014","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-26T11:29:07Z","receivedAt":"2014-02-26T11:29:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 26, 2014 at 12:25:36PM +0100, Vicent Martí wrote:\n\n> On Wed, Feb 26, 2014 at 11:41 AM, Michael Haggerty wrote:\n> > Since time is short, I already started on this. I wrote a first draft\n> > of an introduction for the students. I also started looking for\n> > microprojects. I started going through our source files alphabetically,\n> > and have already found six suggestions by \"bundle.c\", so I don't think\n> > there will be a problem finding enough tiny things to do.\n> \n> Note that for projects that are either libgit2-centric or mix Core Git\n> and libgit2, it would be worth it to the students to submit a pull\n> request on libgit2 (or ideally, on both projects, although that's\n> going to be hard) in order to make themselves familiar with the code\n> base.\n\nYeah, that makes sense. I think if students are thinking primarily about\none of the libgit2 projects, they should focus on interacting with that\ncommunity. Interacting with the mailing list is good, too, but I don't\nsee a need to do a patch for both.\n\nCan you come up with a short list of micro-projects for libgit2, similar\nto what Michael did for Git?\n\n-Peff\n"},{"id":"235378","messageId":"20140226113028.GB3599@sigill.intra.peff.net","threadId":"35953","inReplyTo":"CAFFjANRqKqq_f9SCR4vP3YKUpfk1J2RQdB9G4gnY2OcZivzhXQ@mail.gmail.com","subject":"Re: Git in GSoC 2014","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-26T11:30:28Z","receivedAt":"2014-02-26T11:30:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 26, 2014 at 12:24:13PM +0100, Vicent Martí wrote:\n\n> > One thing I noticed after tg/index-v4-format is both libgit2 and jgit\n> > do not seem to support index v4. So we could add \"index v4 support on\n> > libgit2\" to the idea page. It's a relatively small task though once\n> > you get a hang on index format.\n> \n> That sounds like a nice task for the Summer of Code too, specially\n> with the current effort to make Index v4 more visible in Core Git.\n\nYeah, I'd agree. Want to write it up?\n\n> I wonder if anybody from JGit would also be interested on mentoring\n> for the equivalent task (index v4 on JGit). I've CC'ed Shawn Pearce.\n\nA project that added to both libgit2 and JGit would be cool, but I don't\nknow if that is asking too much of the student (multiple languages and\nprojects is going to increase the time spent on non-code friction).\n\n-Peff\n"},{"id":"235389","messageId":"CAJo=hJs-SaDEmbdWO_NqWQNQBVDszPYx6b50ARytCNwVDZaRwg@mail.gmail.com","threadId":"35953","inReplyTo":"20140226113028.GB3599@sigill.intra.peff.net","subject":"Re: Git in GSoC 2014","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2014-02-26T16:48:13Z","receivedAt":"2014-02-26T16:48:13Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Wed, Feb 26, 2014 at 3:30 AM, Jeff King wrote:\n> On Wed, Feb 26, 2014 at 12:24:13PM +0100, Vicent Martí wrote:\n>\n>> > One thing I noticed after tg/index-v4-format is both libgit2 and jgit\n>> > do not seem to support index v4. So we could add \"index v4 support on\n>> > libgit2\" to the idea page. It's a relatively small task though once\n>> > you get a hang on index format.\n>>\n>> That sounds like a nice task for the Summer of Code too, specially\n>> with the current effort to make Index v4 more visible in Core Git.\n>\n> Yeah, I'd agree. Want to write it up?\n>\n>> I wonder if anybody from JGit would also be interested on mentoring\n>> for the equivalent task (index v4 on JGit). I've CC'ed Shawn Pearce.\n>\n> A project that added to both libgit2 and JGit would be cool, but I don't\n> know if that is asking too much of the student (multiple languages and\n> projects is going to increase the time spent on non-code friction).\n\nI agree, its too much to ask from a single student to add it to both projects.\n\n\nAs far as JGit supporting index v4, I am holding my breath and waiting\nfor index v5. We keep spinning through dircache versions with\nrelatively little gain for each one, but a lot of complexity. As it\nwas a prior version was sort of a disaster with the fixed length\nportion of records being either 62 or 64 bytes depending on a bit set\nper record. Yuck. I haven't been reading every message in the v4 topic\nbut nothing impressed me as being worth my time to implement in JGit,\nother than to be compatible with a version of git-core that won't land\nin Debian stable for at least 2 more years.\n"},{"id":"235390","messageId":"530E2146.1000003@web.de","threadId":"35953","inReplyTo":"20140225154158.GA9038@sigill.intra.peff.net","subject":"Re: Git in GSoC 2014 Suggestion: core.filemode always false for cygwin","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2014-02-26T17:15:50Z","receivedAt":"2014-02-26T17:15:50Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2014-02-25 16.41, Jeff King wrote:\n> I'm pleased to announce that Git has been accepted to this year's Google\n> Summer of Code.\nI'm not sure if this is the right way to propose mini projects,\nbut in case the answer is not no, may I suggest one:\n\nMotivation, the problem:\nSince commit c28facd216b501d41ca76f \n\"cygwin: stop forcing core.filemode=false\" \nGit under cygwin initializes repos with core.filemode = true under NTFS\n\nThis allows a smooth workflow, when e.g. *.sh files are pushed and pulled between\nCygwin, Linux/Unix or Mac OS.\n\nHowever when I visit such a repo under Mingw, then Mingw reads core.filemode =true,\nbut is unable to detect whether the X-bit is set, and reads it as not set.\n\nTherefore \"git status\" thinks that e.g. all *.sh files have lost the executable\nbit, abd reports them as changed.\n\nProposal:\nUnder Mingw, keep trust_executable_bit always false, regardless what\ncore.filemode says.\nActivate NO_TRUSTABLE_FILEMODE in config.mak.uname for Mingw\n(currently it is not used to anything)\n\nKeep the logic in init-db.c to initialize core.filemode = false under Mingw \n\n\nLanguage: C\nDifficulty: easy\n"},{"id":"235403","messageId":"xmqq8usx4pvh.fsf@gitster.dls.corp.google.com","threadId":"35953","inReplyTo":"530DC4D1.4060301@alum.mit.edu","subject":"Re: Git in GSoC 2014","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-26T19:48:18Z","receivedAt":"2014-02-26T19:48:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> See my branch on GitHub [1] or read the appended text below.\n\nVery nice.\n\n> ## Introduction\n>\n> It is strongly recommended that students who want to apply to the Git\n> project for the Summer of Code 2014 should submit a small code-related\n> patch to the Git project as part of their application. Think of these\n> microprojects as the \"Hello, world\" of getting involved with the Git\n> project; the coding aspect of the change can be almost trivial, but to\n> make the change the student has to become familiar with many of the\n> practical aspects of working on the Git project:\n\nI'd suggest one step before all of the below. \n\n * Here (http://thread.gmane.org/{TBD1,TBD2,TBD3...}) are a sample\n set of threads that show how a change and a patch to implement it\n is proposed by a developer X, the problem it attempts to solve,\n the design of the proposed solution and the implementation of\n that design are reviewed and discussed, and that after several\n iterations it resulted in inclusion to our codebase. As a GSoC\n student, you will be playing the role of X and engaging in a\n similar discussion. Get familar with the flow, need for clarity\n on both sides (i.e. you need to clearly defend your design, and\n need to ask clarifications when questions/suggestions you are\n offered are not clear enough), the pace at which the discussion\n takes place, and the general tone of the discussion, to learn\n what is expected of you.\n\nThat would help the later step, namely:\n\n> * Expect feedback, criticism, suggestions, etc. from the mailing list.\n>\n> *Respond to it!* and follow up with improved versions of your\n> change. Even for a trivial patch you shouldn't be surprised if it\n> takes two or more iterations before your patch is accepted. *This\n> is the best part of the Git community; it is your chance to get\n> personalized instruction from very experienced peers!*\n"},{"id":"235441","messageId":"530EEAA2.3030306@alum.mit.edu","threadId":"35953","inReplyTo":"xmqq8usx4pvh.fsf@gitster.dls.corp.google.com","subject":"Re: Git in GSoC 2014","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-02-27T07:34:58Z","receivedAt":"2014-02-27T07:34:58Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/26/2014 08:48 PM, Junio C Hamano wrote:\n> Michael Haggerty writes:\n> \n>> See my branch on GitHub [1] or read the appended text below.\n> \n> Very nice.\n> \n>> ## Introduction\n>>\n>> It is strongly recommended that students who want to apply to the Git\n>> project for the Summer of Code 2014 should submit a small code-related\n>> patch to the Git project as part of their application. Think of these\n>> microprojects as the \"Hello, world\" of getting involved with the Git\n>> project; the coding aspect of the change can be almost trivial, but to\n>> make the change the student has to become familiar with many of the\n>> practical aspects of working on the Git project:\n> \n> I'd suggest one step before all of the below. \n> \n> * Here (http://thread.gmane.org/{TBD1,TBD2,TBD3...}) are a sample\n> set of threads that show how a change and a patch to implement it\n> is proposed by a developer X, the problem it attempts to solve,\n> the design of the proposed solution and the implementation of\n> that design are reviewed and discussed, and that after several\n> iterations it resulted in inclusion to our codebase. As a GSoC\n> student, you will be playing the role of X and engaging in a\n> similar discussion. Get familar with the flow, need for clarity\n> on both sides (i.e. you need to clearly defend your design, and\n> need to ask clarifications when questions/suggestions you are\n> offered are not clear enough), the pace at which the discussion\n> takes place, and the general tone of the discussion, to learn\n> what is expected of you.\n> \n> That would help the later step, namely:\n> \n>> * Expect feedback, criticism, suggestions, etc. from the mailing list.\n>>\n>> *Respond to it!* and follow up with improved versions of your\n>> change. Even for a trivial patch you shouldn't be surprised if it\n>> takes two or more iterations before your patch is accepted. *This\n>> is the best part of the Git community; it is your chance to get\n>> personalized instruction from very experienced peers!*\n\nSounds good. I suggest we make your blob a paragraph before the list of\nbullet points rather than part of the list. Please suggest some \"TBD*\"\nthen I'll add it to the text. Would we also fill in \"X\" with the name\nof the actual student involved in the conversation that is pointed to?\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235491","messageId":"xmqqlhwwz7m7.fsf@gitster.dls.corp.google.com","threadId":"35953","inReplyTo":"530EEAA2.3030306@alum.mit.edu","subject":"Re: Git in GSoC 2014","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-27T19:19:11Z","receivedAt":"2014-02-27T19:19:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> Sounds good. I suggest we make your blob a paragraph before the list of\n> bullet points rather than part of the list. Please suggest some \"TBD*\"\n> then I'll add it to the text. Would we also fill in \"X\" with the name\n> of the actual student involved in the conversation that is pointed to?\n\nI was not thinking about using a student thread (I do not remember\nhaving a good on-list interaction with past GSoC students).\n\nHow about using this one from our recent past:\n\n http://thread.gmane.org/gmane.comp.version-control.git/239068\n\nwhich has the following good points to be used as an example. It:\n\n - involved multiple cycles and multiple reviewers;\n\n - showed good response to the comments from the original author;\n and most importantly\n\n - had everything related to the topic in one single neat thread.\n"},{"id":"235502","messageId":"530F9F59.4030307@alum.mit.edu","threadId":"35953","inReplyTo":"xmqqlhwwz7m7.fsf@gitster.dls.corp.google.com","subject":"Re: Git in GSoC 2014","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-02-27T20:26:01Z","receivedAt":"2014-02-27T20:26:01Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/27/2014 08:19 PM, Junio C Hamano wrote:\n> Michael Haggerty writes:\n> \n>> Sounds good. I suggest we make your blob a paragraph before the list of\n>> bullet points rather than part of the list. Please suggest some \"TBD*\"\n>> then I'll add it to the text. Would we also fill in \"X\" with the name\n>> of the actual student involved in the conversation that is pointed to?\n> \n> I was not thinking about using a student thread (I do not remember\n> having a good on-list interaction with past GSoC students).\n> \n> How about using this one from our recent past:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/239068\n> \n> which has the following good points to be used as an example. It:\n> \n> - involved multiple cycles and multiple reviewers;\n> \n> - showed good response to the comments from the original author;\n> and most importantly\n> \n> - had everything related to the topic in one single neat thread.\n> \n\nChange pushed. Thanks Junio!\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235505","messageId":"xmqqfvn4xpnh.fsf@gitster.dls.corp.google.com","threadId":"35953","inReplyTo":"530F9F59.4030307@alum.mit.edu","subject":"Re: Git in GSoC 2014","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-27T20:32:34Z","receivedAt":"2014-02-27T20:32:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> On 02/27/2014 08:19 PM, Junio C Hamano wrote:\n>> Michael Haggerty writes:\n>> \n>>> Sounds good. I suggest we make your blob a paragraph before the list of\n>>> bullet points rather than part of the list. Please suggest some \"TBD*\"\n>>> then I'll add it to the text. Would we also fill in \"X\" with the name\n>>> of the actual student involved in the conversation that is pointed to?\n>> \n>> I was not thinking about using a student thread (I do not remember\n>> having a good on-list interaction with past GSoC students).\n>> \n>> How about using this one from our recent past:\n>> \n>> http://thread.gmane.org/gmane.comp.version-control.git/239068\n>> \n>> which has the following good points to be used as an example. It:\n>> \n>> - involved multiple cycles and multiple reviewers;\n>> \n>> - showed good response to the comments from the original author;\n>> and most importantly\n>> \n>> - had everything related to the topic in one single neat thread.\n>> \n>\n> Change pushed. Thanks Junio!\n\nThank you for starting this.\n\nAnother point to add to the above three-point list is that it had an\nexample of the original author defending (some of) the design\nchoices he made and reviewers who initially raised questions and/or\nissues agreeing with that choice after the thinking was clearly\nexplained.\n"},{"id":"239281","messageId":"CAH5451mXb2z0oWv0jQuBCwE-x=0Bx0VPXJHSns7T1FsBTUQKOw@mail.gmail.com","threadId":"35953","inReplyTo":"xmqqfvn4xpnh.fsf@gitster.dls.corp.google.com","subject":"Re: Git in GSoC 2014","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2014-04-22T01:06:53Z","receivedAt":"2014-04-22T01:06:53Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"Congrats everyone who was successful in being picked for this year's GSoC.\n\nFabian with \"Line options for git rebase --interactive\" [0]\nBrian Gesiak with \"Unify and Refactor Temporary File Handling\" [1]\nTanay Abhra with \"Git configuration API improvements\" [2]\n\nI look forward to seeing how you go!\n\n[0] https://www.google-melange.com/gsoc/project/details/google/gsoc2014/bafain/5750085036015616\n[1] https://www.google-melange.com/gsoc/project/details/google/gsoc2014/modocache/5639274879778816\n[2] https://www.google-melange.com/gsoc/project/details/google/gsoc2014/tanayabh/5766466041282560\n\nRegards,\n\nAndrew Ardill\n"},{"id":"239283","messageId":"CAN7MxmX4GqWFH5WnZbS2ZdHP1QpQAUmpadRp5euHT+wU2we7BA@mail.gmail.com","threadId":"35953","inReplyTo":"CAH5451mXb2z0oWv0jQuBCwE-x=0Bx0VPXJHSns7T1FsBTUQKOw@mail.gmail.com","subject":"Re: Git in GSoC 2014","fromName":"Brian Gesiak","fromEmail":"modocache@gmail.com","sentAt":"2014-04-22T02:18:46Z","receivedAt":"2014-04-22T02:18:46Z","isPatch":false,"sender":{"key":"modocache@gmail.com","avatar":"https://avatars.githubusercontent.com/u/552921?v=4"},"body":"Thank you!\n\nI'm very excited to be participating in this year's GSoC. Google\nrecommends that students use the next few weeks to get to know their\nmentors, read documentation, and get up to speed to begin working on\ntheir projects. Students have also received instructions on submitting\ntax forms and other paperwork.\n\nAside from filing all the requisite paperwork, I plan on reading\nthrough the extensive set of patches on lock files Michael Haggerty\nsubmitted after my initial proposal. I also plan on consulting with my\nmentor, Jeff King, on some good first steps.\n\nBy the way, my name is Brian Gesiak. I'm a research student at the\nUniversity of Tokyo, specializing in parallel and distributed\ncomputing. If you have any questions regarding my project, \"Unify and\nRefactor Temporary File Handling\", please feel free to contact me via\nthis mailing list, or privately via email. I'm also on GitHub[1] and\nTwitter[2].\n\n[1] https://github.com/modocache\n[2] https://twitter.com/modocache\n\n- Brian Gesiak\n\nOn Tue, Apr 22, 2014 at 10:06 AM, Andrew Ardill wrote:\n> Congrats everyone who was successful in being picked for this year's GSoC.\n>\n> Fabian with \"Line options for git rebase --interactive\" [0]\n> Brian Gesiak with \"Unify and Refactor Temporary File Handling\" [1]\n> Tanay Abhra with \"Git configuration API improvements\" [2]\n>\n> I look forward to seeing how you go!\n>\n> [0] https://www.google-melange.com/gsoc/project/details/google/gsoc2014/bafain/5750085036015616\n> [1] https://www.google-melange.com/gsoc/project/details/google/gsoc2014/modocache/5639274879778816\n> [2] https://www.google-melange.com/gsoc/project/details/google/gsoc2014/tanayabh/5766466041282560\n>\n> Regards,\n>\n> Andrew Ardill\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"}]}