{"thread":{"id":"35858","subject":"Git GSoC 2014","startedAt":"2014-02-13T09:10:37Z","lastAt":"2014-02-15T23:47:15Z","messageCount":15,"participants":["Jeff King","Thomas Rast","Junio C Hamano","Ramkumar Ramachandra","David Kastrup","Vicent Martí","Duy Nguyen","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"234720","messageId":"20140213091037.GA28927@sigill.intra.peff.net","threadId":"35858","inReplyTo":null,"subject":"Git GSoC 2014","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-13T09:10:37Z","receivedAt":"2014-02-13T09:10:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The Google Summer of Code application process is upon us. We have about\n34 hours until the deadline (2014-02-14T19:00 UTC) . That's not very\nmuch time, but I know some people have been thinking about projects for\na while, so I have hope that we can put together an ideas page.\n\nWhat we need immediately is:\n\n  - somebody to be the backup admin (I am assuming I'll be the primary\n    admin, but as always, if somebody else wants to...)\n\n  - ideas ideas ideas\n\n    The email I sent out last week generated some response, but what I\n    really need are people to write up full ideas as they would be read\n    by students (and by GSoC personnel who are reading our application).\n\n    As mentioned in a related thread, I'd really like to avoid just\n    reposting proposals that didn't get any traction in previous years.\n\n    Tomorrow I'll try to look through some of the links that have been\n    posted, or collect stuff from the list. But I really need other\n    people to contribute, or it's going to be a lame list.\n\nI've put the application draft here:\n\n  http://git.github.io/SoC-2014-Org-Application.html\n\nYou can make suggestions in this thread, or edit it by cloning:\n\n  https://github.com/git/git.github.io\n\nand post a patch, or send a pull request, or I should be able to give\npeople push access to the repo. It's a bit of an experiment, in the same\nrealm as the wiki we've used in the past.\n\nThe idea page is there, too, but there's nothing good on it yet:\n\n  http://git.github.io/SoC-2014-Ideas.html\n\n-Peff\n"},{"id":"234746","messageId":"87bnya8z6q.fsf@thomasrast.ch","threadId":"35858","inReplyTo":"20140213091037.GA28927@sigill.intra.peff.net","subject":"Re: Git GSoC 2014","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2014-02-13T21:45:01Z","receivedAt":"2014-02-13T21:45:01Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>   - somebody to be the backup admin (I am assuming I'll be the primary\n>     admin, but as always, if somebody else wants to...)\n\nI can be backup, if Shawn doesn't want it.\n\n>   - ideas ideas ideas\n\nHere's my moonshot:\n\n--- 8< ---\nReplace object loading/writing layer by libgit2\n\nGit reads objects from storage (loose and packed) through functions in\nsha1_file.c.  Most commands only require very simple, opaque read and\nwrite access to the object storage.  As a weatherballoon, show that it\nis feasible to use libgit2 git_odb_* routines for these simple callers.\n\nAim for passing the git test suite using git_odb_* object storage\naccess, except for tests that verify behavior in the face of storage\ncorruption, replacement objects, alternate storage locations, and\nsimilar quirks.  Of course it is even better if you pass the test suite\nwithout exception.\n\nLanguage: C\nDifficulty: hard\nPossible mentors: Thomas Rast and <fill in libgit2 expert>\n--- >8 ---\n\nThat absolutely requires a co-mentor from the libgit2 side to do,\nhowever.  Perhaps you could talk someone into it? ;-)\n\nMotivation: I believe that migrating to libgit2 is the better approach,\nmedium term, than rewriting everything ourselves to be nice, clean and\nthread-safe.  I took a shot a while ago at making the pack reading code\nthread-safe, but it's adding mess when we could simply replace it all by\nthe already thread-safe libgit2 calls.  It also helps shake out\nincompatibilities in libgit2.\n\nDownside: not listing \"code merged\" as a goal may not make the project\nas shiny, neither for Git nor for the student.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"234748","messageId":"xmqqk3cyk4oz.fsf@gitster.dls.corp.google.com","threadId":"35858","inReplyTo":"87bnya8z6q.fsf@thomasrast.ch","subject":"Re: Git GSoC 2014","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-13T22:50:36Z","receivedAt":"2014-02-13T22:50:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <tr@thomasrast.ch> writes:\n\n> Downside: not listing \"code merged\" as a goal may not make the project\n> as shiny, neither for Git nor for the student.\n\nI'd actually view that as an upside. This sounds like a good first\nstep for a feasibility study that is really necessary.\n\nI wonder why the handling of storage corruption and replacement\ncould be left broken, though. Is that because libgit2 has known\nbreakages in these areas, or is there some other reason?\n"},{"id":"234753","messageId":"CALkWK0mR=9ZD256bHx9d=W9ayqn5bOETWBQLW_kvRSy-GeQK4Q@mail.gmail.com","threadId":"35858","inReplyTo":"20140213091037.GA28927@sigill.intra.peff.net","subject":"Re: Git GSoC 2014","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-02-13T23:17:17Z","receivedAt":"2014-02-13T23:17:17Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n>   - ideas ideas ideas\n\nI'll throw in a few ideas from half-finished work.\n\n1. Speed up git-rebase--am.sh\n\nCurrently, git-rebase--am.sh is really slow because it dumps each\npatch to a file using git-format-patch, and picks it up to apply\nsubsequently using git-am. Find a way to speed this up, without\nsacrificing safety. You can use the continuation features of\ncherry-pick, and dump to file only to persist state in the case of a\nfailure.\n\nLanguage: Shell script, C\nDifficulty: Most of the difficulty lies in \"what to do\", not so much\n\"how to do it\". Might require modifying cherry-pick to do additional\nwork on failure.\n\n2. Invent new conflict style\n\nAs an alternative to the diff3 conflict style, invent a conflict style\nthat shows the original unpatched segment along with the raw patch\ntext. The user can then apply the patch by hand.\n\nLanguage: C\nDifficulty: Since it was first written, very few people have touched\nthe xdiff portion of the code. Since the area is very core to git, the\nseries will have to go through a ton of iterations.\n\n3. Rewrite git-branch to use git-for-each-ref\n\nFor higher flexibility in command-line options and output format, use\ngit for-each-ref to re-implement git-branch. The first task is to grow\nfeatures that are in branch but not fer into fer (like --column,\n--merged, --contains). The second task is to refactor fer so that an\nexternal program can call into it.\n\nLanguage: C\nDifficulty: fer was never written with the idea of being reusable; it\ntherefore persists a lot of global state, and even leaks memory in\nsome places. Refactoring it to be more modern is definitely a\nchallenge.\n\n4. Implement @{publish}\n(I just can't find the time to finish this)\n\n@{publish} is a feature like @{upstream}, showing the state of the\npublish-point in the case of triangular workflows. Implement this\nwhile sharing code with git-push, and polish it until the prompt shows\npublish-state.\n\nLanguage: C, Shell script\nDifficulty: Once you figure out how to share code with git-push, this\ntask should be relatively straightforward.\n"},{"id":"234756","messageId":"87vbwi6toj.fsf@thomasrast.ch","threadId":"35858","inReplyTo":"xmqqk3cyk4oz.fsf@gitster.dls.corp.google.com","subject":"Re: Git GSoC 2014","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2014-02-14T07:26:52Z","receivedAt":"2014-02-14T07:26:52Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Thomas Rast <tr@thomasrast.ch> writes:\n>\n>> Downside: not listing \"code merged\" as a goal may not make the project\n>> as shiny, neither for Git nor for the student.\n>\n> I'd actually view that as an upside. This sounds like a good first\n> step for a feasibility study that is really necessary.\n>\n> I wonder why the handling of storage corruption and replacement\n> could be left broken, though. Is that because libgit2 has known\n> breakages in these areas, or is there some other reason?\n\nIt's because I don't know enough about what libgit2's state is, and I\nwanted to keep the scope limited.  Naturally, the next step would then\nbe to implement the lacking functionality (if any) in libgit2 so that\nthe test suite passes.  I just don't know if that's trivial, or\nsomething for the \"if we have time\" section of the project, or too much\nwork.\n\n(I did do a quick \"can we reasonably link against libgit2\" test where I\ngave git-cat-file a --libgit2 option that loads blobs with libgit2.\nThere are some name collisions in the git_config* identifiers that need\nto be resolved, but otherwise it seems entirely possible.)\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"234759","messageId":"87d2iq58qk.fsf@fencepost.gnu.org","threadId":"35858","inReplyTo":"87bnya8z6q.fsf@thomasrast.ch","subject":"Re: Git GSoC 2014","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-14T09:44:35Z","receivedAt":"2014-02-14T09:44:35Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Thomas Rast <tr@thomasrast.ch> writes:\n\n> Here's my moonshot:\n>\n> --- 8< ---\n> Replace object loading/writing layer by libgit2\n>\n> Git reads objects from storage (loose and packed) through functions in\n> sha1_file.c.  Most commands only require very simple, opaque read and\n> write access to the object storage.  As a weatherballoon, show that it\n> is feasible to use libgit2 git_odb_* routines for these simple callers.\n>\n> Aim for passing the git test suite using git_odb_* object storage\n> access, except for tests that verify behavior in the face of storage\n> corruption, replacement objects, alternate storage locations, and\n> similar quirks.  Of course it is even better if you pass the test suite\n> without exception.\n\n[...]\n\n> That absolutely requires a co-mentor from the libgit2 side to do,\n> however.  Perhaps you could talk someone into it? ;-)\n>\n> Motivation: I believe that migrating to libgit2 is the better approach,\n> medium term, than rewriting everything ourselves to be nice, clean and\n> thread-safe.  I took a shot a while ago at making the pack reading code\n> thread-safe, but it's adding mess when we could simply replace it all by\n> the already thread-safe libgit2 calls.  It also helps shake out\n> incompatibilities in libgit2.\n\nThat would either require forking libgit2 for Git use or stop dead any\ncontributions to that rather central part of the git codebase from\ncontributors not wanting their contributions to get reused in binary\nproprietary software.\n\nIt would also mean that no serious forward-going work (like developing\nnew packing formats or network protocols) can be done on a pure GPLv2\ncodebase any more.  So anybody insisting on contributing work under the\ncurrent Git license only would be locked out from working on significant\nparts of Git and could no longer propose changes in central parts.\n\nNow this can all be repealed by the \"developing the atomic bomb does not\nmean that one has to use it\" argument but even if one does not use it,\nthe world with and without it are different worlds and occupy mindshare\nand suggest \"solutions\" and \"diplomacy\" involving it.\n\nSo this is definitely a large step towards a situation where erosion of\nthe existing license and related parts of the community becomes more\nattractive.\n\nThere is the rationale \"we can always say \"no\" at the end\".  How do you\nexplain this \"no\" to the student who invested significant amounts of\nwork into this, in a project proposed by the Git developers?\n\nThis definitely should not be \"we'll think about it if and when that\nproject is finished\" material.\n\n-- \nDavid Kastrup\n"},{"id":"234761","messageId":"20140214104139.GA28570@sigill.intra.peff.net","threadId":"35858","inReplyTo":"CALkWK0mR=9ZD256bHx9d=W9ayqn5bOETWBQLW_kvRSy-GeQK4Q@mail.gmail.com","subject":"Re: Git GSoC 2014","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-14T10:41:39Z","receivedAt":"2014-02-14T10:41:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 13, 2014 at 06:17:17PM -0500, Ramkumar Ramachandra wrote:\n\n> I'll throw in a few ideas from half-finished work.\n\nThanks. A few comments:\n\n> 1. Speed up git-rebase--am.sh\n> \n> Currently, git-rebase--am.sh is really slow because it dumps each\n> patch to a file using git-format-patch, and picks it up to apply\n> subsequently using git-am. Find a way to speed this up, without\n> sacrificing safety. You can use the continuation features of\n> cherry-pick, and dump to file only to persist state in the case of a\n> failure.\n\nIsn't the merge backend faster? I thought that was the point of it.\n\n> 3. Rewrite git-branch to use git-for-each-ref\n> \n> For higher flexibility in command-line options and output format, use\n> git for-each-ref to re-implement git-branch. The first task is to grow\n> features that are in branch but not fer into fer (like --column,\n> --merged, --contains). The second task is to refactor fer so that an\n> external program can call into it.\n\nI actually have this about 95% done, waiting for the patches to be\npolished. So I don't think it makes a good GSoC project (it would be\nstupid to start from scratch, and polishing my patches is a lame\nproject).\n\n> 4. Implement @{publish}\n> (I just can't find the time to finish this)\n> \n> @{publish} is a feature like @{upstream}, showing the state of the\n> publish-point in the case of triangular workflows. Implement this\n> while sharing code with git-push, and polish it until the prompt shows\n> publish-state.\n\nI think this could be a good GSoC-sized topic. I'm going to adjust the\ntitle to be \"better support for triangular workflows\". I think they may\nwant to examine other issues in the area, rather than drilling down on\n@{publish} in particular (but ultimately, it is up to the student to\npropose what they want to do).\n\n-Peff\n"},{"id":"234770","messageId":"CALkWK0nXbfoe7697m27o7b+vepkOWj+vpJJWRy9EkJeZkTyekw@mail.gmail.com","threadId":"35858","inReplyTo":"20140214104139.GA28570@sigill.intra.peff.net","subject":"Re: Git GSoC 2014","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-02-14T15:30:28Z","receivedAt":"2014-02-14T15:30:28Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jeff King wrote:\n>> 1. Speed up git-rebase--am.sh\n>\n> Isn't the merge backend faster? I thought that was the point of it.\n\nI suppose, but I thought git-rebase--am.sh (the default flavor) could\nbe improved by leveraging relatively new cherry-pick features; I\nassumed that the reason it was using format-patch/ am was because it\nwas written before cherry-pick matured. Alternatively, can you think\nof a project that involves working on the sequencer?\n\n>> 3. Rewrite git-branch to use git-for-each-ref\n>\n> I actually have this about 95% done, waiting for the patches to be\n> polished. So I don't think it makes a good GSoC project (it would be\n> stupid to start from scratch, and polishing my patches is a lame\n> project).\n\nOh. I look forward to using a nicer git-branch soon.\n\n>> 4. Implement @{publish}\n>\n> I think this could be a good GSoC-sized topic. I'm going to adjust the\n> title to be \"better support for triangular workflows\". I think they may\n> want to examine other issues in the area, rather than drilling down on\n> @{publish} in particular (but ultimately, it is up to the student to\n> propose what they want to do).\n\nThat makes the project a little more open-ended then. I like it.\n\nI was hoping you'd have more comments on \"3. Invent new conflict\nstyle\". Although I'm not sure the conflict style I proposed would be\nterribly useful in the general case, it'll give the student an\nopportunity to look at older/ lesser-known portions of the codebase.\n"},{"id":"234779","messageId":"20140214172907.GA14610@sigill.intra.peff.net","threadId":"35858","inReplyTo":"CALkWK0nXbfoe7697m27o7b+vepkOWj+vpJJWRy9EkJeZkTyekw@mail.gmail.com","subject":"Re: Git GSoC 2014","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-14T17:29:07Z","receivedAt":"2014-02-14T17:29:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 14, 2014 at 10:30:28AM -0500, Ramkumar Ramachandra wrote:\n\n> > Isn't the merge backend faster? I thought that was the point of it.\n> \n> I suppose, but I thought git-rebase--am.sh (the default flavor) could\n> be improved by leveraging relatively new cherry-pick features; I\n> assumed that the reason it was using format-patch/ am was because it\n> was written before cherry-pick matured.\n\nI think that's somewhat the case. But the am technique also knows a lot\nof tricks that cherry-pick doesn't. For example, there is currently a\nbug where \"git rebase --keep-empty --whitespace=fix\" silently ignores\nthe latter option, because the former causes it to follow a cherry-pick\ncode path.\n\nSo I am a little hesitant in pushing more code paths down the\ncherry-pick route (though it would be OK if we correctly identified\n_when_ we could use cherry-pick for performance, and only kick in then).\n\n> Alternatively, can you think of a project that involves working on the\n> sequencer?\n\nSo yeah, obviously this is all tied up with the sequencer. In the spirit\nof \"let's not re-propose old projects\", I shied away from suggesting\n\"finish up the sequencer\". I know that the past projects did make\nprogress, and that is a good thing. But I also think it doesn't make for\na good bite-sized chunk.\n\n> >> 3. Rewrite git-branch to use git-for-each-ref\n> >\n> > I actually have this about 95% done, waiting for the patches to be\n> > polished. So I don't think it makes a good GSoC project (it would be\n> > stupid to start from scratch, and polishing my patches is a lame\n> > project).\n> \n> Oh. I look forward to using a nicer git-branch soon.\n\nActually, it is mostly about making a nicer git-for-each-ref, as I am\npulling out the ref selection code (which is more advanced in \"git tag\"\nand \"git branch\") and using it everywhere. So in that sense, maybe I am\nnot shooting for what you want. I think you want the follow-on to that,\nwhich is to pull out the formatting code (which is more advanced in\nfor-each-ref), and let it be used everywhere.\n\nI added this into the ideas page, but noting that there were two sides\nto it, and that one would need to examine and build on existing work (I\nknow there was some discussion and experiments on the formatting side,\ntoo).\n\n> I was hoping you'd have more comments on \"3. Invent new conflict\n> style\". Although I'm not sure the conflict style I proposed would be\n> terribly useful in the general case, it'll give the student an\n> opportunity to look at older/ lesser-known portions of the codebase.\n\nI almost said more. :) I am not sure I have in my mind what a useful\nnew format would look like, and I would worry that we are leading the\nstudent into a bit of a trap, as they need to both code, but also invent\na new and useful format.\n\nBut one thing I was really hoping for with these project descriptions\n(and I think we got) is that they are not completed project proposals.\nThey are the kernels of ideas that the student will need to develop into\nfull proposals. I would much rather have a student who reads that and\nsays \"I have a brilliant idea for a format\" and proposes it, rather than\none who blindly says \"OK, I'll implement your idea\". Getting the former\nis much less likely, but if we do, I think it will lead to a much higher\nquality project.\n\nSo I included it as-is, and I am curious to see what proposals we get.\n:)\n\nThanks again for your list. I marked you as a potential mentor for the\nconflict-style project; given the right proposal, I'd be happy to mentor\nit, too (and without the right proposal, I do not think we should do it\nat all). I also listed both you and me as potential mentors for\n@{publish}, since we have both looked at the problem space. If you can't\nmake the time commitment, that's fine; I can do it (and we don't need to\ndecide until later anyway).\n\n-Peff\n"},{"id":"234781","messageId":"CAFFjANTSy3_2yNv=og71RmVWV2ET76gD0XHFA+QRM0boCruDrg@mail.gmail.com","threadId":"35858","inReplyTo":"87bnya8z6q.fsf@thomasrast.ch","subject":"Re: Git GSoC 2014","fromName":"Vicent Martí","fromEmail":"tanoku@gmail.com","sentAt":"2014-02-14T17:53:02Z","receivedAt":"2014-02-14T17:53:02Z","isPatch":false,"sender":{"key":"tanoku@gmail.com","avatar":"https://gravatar.com/avatar/271386991cb4c2b8f1e1ed1d059f3422cc3485de7a598f65043f70be021d095b?d=mp&s=160"},"body":"On Thu, Feb 13, 2014 at 10:45 PM, Thomas Rast <tr@thomasrast.ch> wrote:\n> Replace object loading/writing layer by libgit2\n>\n> Git reads objects from storage (loose and packed) through functions in\n> sha1_file.c.  Most commands only require very simple, opaque read and\n> write access to the object storage.  As a weatherballoon, show that it\n> is feasible to use libgit2 git_odb_* routines for these simple callers.\n>\n> Aim for passing the git test suite using git_odb_* object storage\n> access, except for tests that verify behavior in the face of storage\n> corruption, replacement objects, alternate storage locations, and\n> similar quirks.  Of course it is even better if you pass the test suite\n> without exception.\n>\n> Language: C\n> Difficulty: hard\n> Possible mentors: Thomas Rast and <fill in libgit2 expert>\n\nNote that we have several people in the libgit2 team that are willing\n(and excited) to mentor or co-mentor this project or any of the other\nlibgit2 related projects that have been proposed.\n\nProspective list is\n\n- Vicent Marti\n- Russell Belfer\n- Ed Thomson\n- Carlos Martin (past GSoC student)\n\nSo there shouldn't be any mentor shortage.\n\nCheers,\nvmg\n"},{"id":"234783","messageId":"20140214185628.GA18696@sigill.intra.peff.net","threadId":"35858","inReplyTo":"20140213091037.GA28927@sigill.intra.peff.net","subject":"Re: Git GSoC 2014","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-14T18:56:28Z","receivedAt":"2014-02-14T18:56:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 13, 2014 at 04:10:37AM -0500, Jeff King wrote:\n\n> The Google Summer of Code application process is upon us. We have about\n> 34 hours until the deadline (2014-02-14T19:00 UTC) . That's not very\n> much time, but I know some people have been thinking about projects for\n> a while, so I have hope that we can put together an ideas page.\n\nJust to let everybody know, the application is submitted. For reference,\nI've updated the submitted application text here:\n\n  http://git.github.io/SoC-2014-Org-Application.html\n\nI've collected the discussion on the list on the ideas page:\n\n  http://git.github.io/SoC-2014-Ideas.html\n\nGoogle folks will be looking at it over the next week, but prospective\nstudents probably won't see it until we are accepted to the program,\nwhich would happen Feb 24th.\n\nPlease feel free to continue discussing or updating the ideas page in\nthe meantime. I think there is enough there already to show Google what\nwe are thinking about, but ultimately the students are the ones whom the\npage is meant to serve.  Anything we can do to improve it before they\nread it is a good thing.\n\n-Peff\n"},{"id":"234852","messageId":"87fvnk4ljl.fsf@thomasrast.ch","threadId":"35858","inReplyTo":"87d2iq58qk.fsf@fencepost.gnu.org","subject":"Re: Git GSoC 2014","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2014-02-15T12:17:50Z","receivedAt":"2014-02-15T12:17:50Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"David Kastrup <dak@gnu.org> writes:\n\n> Thomas Rast <tr@thomasrast.ch> writes:\n>\n>> Motivation: I believe that migrating to libgit2 is the better approach,\n>> medium term, than rewriting everything ourselves to be nice, clean and\n>> thread-safe.  I took a shot a while ago at making the pack reading code\n>> thread-safe, but it's adding mess when we could simply replace it all by\n>> the already thread-safe libgit2 calls.  It also helps shake out\n>> incompatibilities in libgit2.\n>\n> That would either require forking libgit2 for Git use or stop dead any\n> contributions to that rather central part of the git codebase from\n> contributors not wanting their contributions to get reused in binary\n> proprietary software.\n>\n> It would also mean that no serious forward-going work (like developing\n> new packing formats or network protocols) can be done on a pure GPLv2\n> codebase any more.  So anybody insisting on contributing work under the\n> current Git license only would be locked out from working on significant\n> parts of Git and could no longer propose changes in central parts.\n>\n> Now this can all be repealed by the \"developing the atomic bomb does not\n> mean that one has to use it\" argument but even if one does not use it,\n> the world with and without it are different worlds and occupy mindshare\n> and suggest \"solutions\" and \"diplomacy\" involving it.\n>\n> So this is definitely a large step towards a situation where erosion of\n> the existing license and related parts of the community becomes more\n> attractive.\n>\n> There is the rationale \"we can always say \"no\" at the end\".  How do you\n> explain this \"no\" to the student who invested significant amounts of\n> work into this, in a project proposed by the Git developers?\n>\n> This definitely should not be \"we'll think about it if and when that\n> project is finished\" material.\n\nYes, all of this is true.  However, you are painting a big devil on the\nwall.\n\nFirst, one very plausible outcome of such a project is that there is a\nmore narrowly defined interface to the object-reading component of the\ngit codebase, and that libgit2 can be \"plugged in\" at that interface\ninstead of the existing routines.  This would help both clean up our\ncode, and test libgit2 against existing git tests.\n\nYour scenario above mostly applies if and when we really go the way of\nmy dream and scrap the code that is in git.  (I have similar long-term\ndreams for other git components like ref storage and diffs, but that's\njust me.)\n\nSecond, how many contributions would actually have been prevented by\nGPLv2+LE licensing?\n\nThe only data I have on this is libgit2/git.git-authors, which records\nwho has consented for their _existing_ code to be relicensed.  I\nconsider this to be a higher barrier than contributing new code, since\nthere's no clear gain for the author in the relicensing.\n\nThat file is a sizeable list, and covers most contributions to\nsha1_file.c lately:\n\n  [git shortlog -sn --since=2.year.ago sha1_file.c, edited in the answer\n  from git.git-authors]\n\n   ok     15  Jeff King\n   ok     11  Michael Haggerty\n           6  Nguyễn Thái Ngọc Duy\n   ok      5  Christian Couder\n   ask     5  Thomas Rast\n   ok      2  Brandon Casey\n           2  Heiko Voigt\n           2  Pete Wyckoff\n           1  Felipe Contreras\n           1  Joachim Schmitz\n           1  Johan Herland\n   ask     1  Jonathan Nieder\n           1  Ramsay Allan Jones\n           1  Steven Walter\n           1  Vicent Marti\n\n  (My \"ask\" is because of $DAYJOB legal reasons, and in fact the\n  contributions above fall under the \"ok before Oct 7, 2013\" remark in\n  git.git-authors.)\n\nIt also includes an \"ok\" from Nicolas Pitre, who has been the driving\nforce behind packv5 development.  The only thing that makes me uneasy is\nthat Duy is not in the list (Duy, have you been asked by libgit2 about\npossible relicensing?).  Other than that, I do not see a cause for\nconcern.\n\n\nConversely, contributions to clean up that corner of code have not\nexactly been forthcoming at a great rate in the first place.  The recent\nwork I can recall off hand was bug fixing and the introduction of pack\nbitmaps.  The only work that I know is within reach is the packv5 drafts\nthat Nicolas and Duy tossed around.\n\n(It is an odd coincidence that this thread runs in parallel with [1].\nIf that gains some traction, more power to them.)\n\n\nSo you may disagree, and other contributors should probably comment on\ntheir stance.  But taking the above together, I think we stand to gain\nmore than we would lose.\n\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/241965\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"234854","messageId":"CACsJy8DmkBUZwgFeaoh1z=XbjdH1i6RosT-Ue1eYGwAkzH5nTQ@mail.gmail.com","threadId":"35858","inReplyTo":"87fvnk4ljl.fsf@thomasrast.ch","subject":"Re: Git GSoC 2014","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-02-15T12:35:55Z","receivedAt":"2014-02-15T12:35:55Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, Feb 15, 2014 at 7:17 PM, Thomas Rast <tr@thomasrast.ch> wrote:\n> It also includes an \"ok\" from Nicolas Pitre, who has been the driving\n> force behind packv5 development.  The only thing that makes me uneasy is\n\nNit: pack v4. You are probably confused with index v5, which is also\ncooking for a while now.\n\n> that Duy is not in the list (Duy, have you been asked by libgit2 about\n> possible relicensing?).\n\nI don't remember. But for the record I'm OK with relicensing my\ncontributions in git.git for inclusion in libgit2.\n-- \nDuy\n"},{"id":"234856","messageId":"87fvnk1q9u.fsf@fencepost.gnu.org","threadId":"35858","inReplyTo":"87fvnk4ljl.fsf@thomasrast.ch","subject":"Re: Git GSoC 2014","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-02-15T13:03:57Z","receivedAt":"2014-02-15T13:03:57Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Thomas Rast <tr@thomasrast.ch> writes:\n\n> David Kastrup <dak@gnu.org> writes:\n>\n>> This definitely should not be \"we'll think about it if and when that\n>> project is finished\" material.\n>\n> Yes, all of this is true.  However, you are painting a big devil on\n> the wall.\n\n[...]\n\n> Your scenario above mostly applies if and when we really go the way of\n> my dream and scrap the code that is in git.\n\nSo it's not \"a big devil\" I am painting but rather the consequences if\neverything goes according to plan.\n\n> (I have similar long-term dreams for other git components like ref\n> storage and diffs, but that's just me.)\n>\n> Second, how many contributions would actually have been prevented by\n> GPLv2+LE licensing?\n\nThat's not as much the question as to how many will be prevented in\nfuture by such a step.\n\nThe libgit2 community is different from that of Git and with a different\nfocus.  If you take a look at its front page, you'll see statements like\n\"Link with open and proprietary software.  No strings attached.\" and\n\"Trusted and used in production by GitHub, Microsoft, [...]\".\n\nA fusion with this project and its aims and licensing will have\nconsequences regarding which developers and users are attracted to Git.\n\nThe \"act first, think later\" approach is not really doing anybody\nfavors, and I don't consider it fair to GSoC students to employ them for\nmaking this proposal gain leverage: one should first think this through\non behalf of the project before putting students to work on this so that\nthey know reasonably well what will happen with their work.\n\nThe kind of \"Now that we made $x do $y, we are obliged to do $z.\"\nscenario is easy to avoid by _first_ contemplating whether or not $z is\nwhere one wants to go.\n\nThat's not \"painting a devil\" but common sense.  I'm not saying that the\nanswer is in any way self-evident.  Merely that the best time to answer\nit is _before_ getting invested.\n\n> The only data I have on this is libgit2/git.git-authors, which records\n> who has consented for their _existing_ code to be relicensed.  I\n> consider this to be a higher barrier than contributing new code, since\n> there's no clear gain for the author in the relicensing.\n\nI consider it a lower barrier since the work is already done, and the\nauthors did not when doing it think about proprietary spinoffs.\n\nBut that's a minor point.  All I am saying is that there are different\nopinions possible, and picking a particular path for future development\nwill in either way influence who wants to be part of the respective\ncommunities.\n\n-- \nDavid Kastrup\n"},{"id":"234867","messageId":"CAJo=hJsk=m-R+pGf3rT+7BLBnAYsXd-xw-ztbjw4uHd_mO=-cQ@mail.gmail.com","threadId":"35858","inReplyTo":"87fvnk4ljl.fsf@thomasrast.ch","subject":"Re: Git GSoC 2014","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2014-02-15T23:47:15Z","receivedAt":"2014-02-15T23:47:15Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Sat, Feb 15, 2014 at 4:17 AM, Thomas Rast <tr@thomasrast.ch> wrote:\n> David Kastrup <dak@gnu.org> writes:\n>\n>> Thomas Rast <tr@thomasrast.ch> writes:\n>>\n>>> Motivation: I believe that migrating to libgit2 is the better approach,\n>>> medium term, than rewriting everything ourselves to be nice, clean and\n>>> thread-safe.  I took a shot a while ago at making the pack reading code\n>>> thread-safe, but it's adding mess when we could simply replace it all by\n>>> the already thread-safe libgit2 calls.  It also helps shake out\n>>> incompatibilities in libgit2.\n>>\n>> That would either require forking libgit2 for Git use or stop dead any\n>> contributions to that rather central part of the git codebase from\n>> contributors not wanting their contributions to get reused in binary\n>> proprietary software.\n>>\n>> It would also mean that no serious forward-going work (like developing\n>> new packing formats or network protocols) can be done on a pure GPLv2\n>> codebase any more.  So anybody insisting on contributing work under the\n>> current Git license only would be locked out from working on significant\n>> parts of Git and could no longer propose changes in central parts.\n>>\n>> Now this can all be repealed by the \"developing the atomic bomb does not\n>> mean that one has to use it\" argument but even if one does not use it,\n>> the world with and without it are different worlds and occupy mindshare\n>> and suggest \"solutions\" and \"diplomacy\" involving it.\n>>\n>> So this is definitely a large step towards a situation where erosion of\n>> the existing license and related parts of the community becomes more\n>> attractive.\n>>\n>> There is the rationale \"we can always say \"no\" at the end\".  How do you\n>> explain this \"no\" to the student who invested significant amounts of\n>> work into this, in a project proposed by the Git developers?\n>>\n>> This definitely should not be \"we'll think about it if and when that\n>> project is finished\" material.\n>\n> Yes, all of this is true.  However, you are painting a big devil on the\n> wall.\n...\n> Second, how many contributions would actually have been prevented by\n> GPLv2+LE licensing?\n\nInteresting data point, I helped get libgit2 started in the first few\ndays of its existence and discussed the license on the mailing list. I\neventually stopped contributing, partly because of the GPLv2+LE\nlicense it uses.\n\n:-)\n\nI am not as interested in using the GPL for my work as David Kastrup\nis, but I wasn't really thrilled with GPLv2+LE.\n"}]}