{"thread":{"id":"18701","subject":"[RFC] GSoC Proposal v2:","startedAt":"2009-04-03T03:15:28Z","lastAt":"2009-04-03T04:22:29Z","messageCount":2,"participants":["P Baker","Sverre Rabbelier"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"110264","messageId":"526944450904022015n67be674dwfab5d3dc597c806b@mail.gmail.com","threadId":"18701","inReplyTo":null,"subject":"[RFC] GSoC Proposal v2:","fromName":"P Baker","fromEmail":"me@retrodict.com","sentAt":"2009-04-03T03:15:28Z","receivedAt":"2009-04-03T03:15:28Z","isPatch":false,"sender":{"key":"me@retrodict.com","avatar":null},"body":"See below for a revised project application. More comments would be\nappreciated. Thanks to Shawn, Dscho and Andreas for already offering\nsome help!\n\nTitle: git-submodule for multiple, active developers on active trees\n\nAbstract:\n\n\tThis project focuses on upgrading git-submodule to manage code created in\nexternal projects in ways that allow users to safely branch and merge that\ncode without loss of data or routine merge conflicts. This will incorporate\nsome unfinished patches, but will also include making substantial changes to\nthe underlying code of git-submodule.\n\nContent:\n\n\tToday, git-submodule is a solid component designed to allow developers to\nleverage the work of others by incorporating external code into a project.\nHowever, as most core developers are not heavy users of the feature its\nimplementation is underdeveloped [1], which creates problems when it does not\nact according to developers’ expectations based on the robustness of other git\nfeatures. This project would devote a summer of work to filling in the gaps so\nthat git-submodule contains the features necessary to fully exploit its\npotential to track, update and edit external codebases incorporated into a\nsuper-project.\n\tSubmodules are unique in their goal. As opposed to “remotes,” which also\nincorporate external code into a project, submodules maintain the distinct\nnature of code and separate projects’ histories. This is perfect for the\nintended nature of “embedding foreign repositories in dedicated subdirectories\nof the source tree.”[2] For example, managing plug-ins within a larger,\nstandalone project that depends on them is an important technique to leverage\nothers' work and shorten the development process made much more difficult by\nthe shortcomings of git-submodule and require laborious workarounds or\nexplicit manual content management.[3] Adding the most commonly requested\nfeatures would give current users a desired tool, boost git’s credibility by\nproviding a common feature among revision control systems, make the adoption\nof git for new and existing projects easier and, as a result, likely boost\ngit’s overall usage.\n\tThis project will consist of several stages: an initial community based\ndesign review and investigation of specific requirements; specifying and\ndocumenting the planned changes; and writing, debugging and merging the code\nand related tests. A few specific changes that this project will likely\ninclude are:\n\n*move objects of submodules into base .git/ directory\n**This would accomplish two goals. It would protect submodules from being\noverwritten, and implicitly, modified content from potentially being lost.\nThis can happen when a branch with a submodule is replaced by checking out a\nbranch of a super-project that does not contain the submodule. As well, this\nwould centralize submodule management into one location. The added benefits of\nfully using git's ability to branch and merge submodules makes it worth adding\ncomplexity in the .git directory to accomplish this. Basically, this would add\nsupport for local branches of submodules.[4]\n\n*make git-submodule help with merging\n**Instead of issuing merge conflicts on updated submodule references, this\nwill allow submodules on default detached HEAD so that changes from the local\nrepo can be committed without first pulling changes from the shared\nrepository. This made 'submodules...unsuitable for active development'.[5]\nClearly losing this kind of functionality impairs the overall usability of git\nand should be fixed. Essentially, this would enable branch and merging between\nlocal and remote repositories.\n\n*protect changes in local submodules when doing “git submodule update”\n**This is similar to the previous point, in that changes need to be protected\nor merged or warnings issued when updating the submodule. The potential to\nlose work with no warning is a big no-no.\n\n*prevent unintentional super-project push without previous submodule push\n**A common mistake made when using git-submodule is to commit and push the\nsuper-project, without first pushing the latest commits in the submodule. This\nproblem will require some brainstorming to find a good solution.\n\n*make git submodules easy to remove\n** Adding a submodule has UI, removing one should as well.[6] There shouldn't\nhave to be a tutorial on how to do it.[7]\n\nThese major changes are in addition to some bug-fixes which include: git\nsubmodule summary should output to the pager by default; and finishing the\nimplementation of git submodule recurse [8]. The tentative timeline is:\n\nEnd of May – Conclusively finish the public discussion regarding\nfeatures to be added to git-submodule\nBeginning of June – work on git submodule remove as a way to become\nfamiliar with the code and accomplish an \"easy\" first win.\nMiddle of June – move objects of submodules into base .git/ directory.\nThis should take up the majority of the month and will likely\nconstitute the major portion of contributed code for the summer.\nMiddle of July – make submodules deal with updated references, this is\nthe second key component of upgrading submodules for use on active\ntrees.\nEnd of July – protect changes in local submodules during “git\nsubmodule update”. This will interact with the previous work, and\nmight implicitly be solved by it, if not, it\nMiddle of August – if time permits, finish git submodule recurse.\n\nThis timeline should allow adequate flexibility while establishing deadlines\nthat ensure that the project will be completed in a timely and efficient\nmanner. Most development will need to occur within git-submodules.sh, without\nchanging much plumbing, however, other files might be affected by more\nsubstantial changes.\n\tWhile git-submodule is stable and operational, it has not seen much change\nbeyond bug-fixes. After reaching its current feature complete status, the last\ntime a feature of any novelty was included in a public release was August\n2008. However, some work has already been started by different contributors\nwho have started patches, but not seen their inclusion into a public\nrelease.[9][10] The project will incorporate and conclude these patches.\n\tAt the end of the project, one metric by which to evaluate its success will\nbe its acceptance in online communities. The final goal is to make git a\ntop-tier version control system in its management of external code\nrepositories. My main usage of git started as an intern when managing a summer\nproject that had many of the requirements that make git-submodule problematic:\nbuilt in a web application framework and dependent on plug-ins, some of which\nwere managed in SVN. Even though the Ruby on Rails community has popularized\nthe use of git-submodule to manage plug-ins, and quite a bit has been written\non the topic, a significant portion of explanations end either in frustration\nor convoluted workarounds. Personally, the problems and confusing nature of\ngit-submodule led me to give up on it altogether, and manage the code and\nupdates to it by hand. The need for improvement is clearly indicated by the\nfrequency with which improvements are requested (for example, in the Git 2009\nUser Survey responses [11]).\n\tI currently am finishing my sophomore year as an Electrical Engineer at the\nUniversity of Pennsylvania (and dual-majoring in the Wharton School of\nBusiness). I started to develop professionally when I took a year off between\nhigh school and college to work for a small firm in Silicon Valley, California\ndeveloping diagnostic imaging software for quality assurance and research on\ntheir products. Last summer I developed a Ruby on Rails-based engine to test\nuser-designed investment strategies for QED Benchmark, a boutique hedge fund.\n\n[1]http://article.gmane.org/gmane.comp.version-control.git/79167\n[2]http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html\n[3]http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html?showComment=1210125780000#c1605130977296198852\n[4]http://marc.info/?l=git&m=121726233001151&w=2\n[5]http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html?showComment=1211380200000#c3897235118548537475\n[6]See http://pitupepito.homelinux.org/?p=24, for an example of how\nthe current process is hard.\n[7]http://git.or.cz/gitwiki/GitSubmoduleTutorial\n[8]http://article.gmane.org/gmane.comp.version-control.git/69834\n[9]http://marc.info/?l=git&m=121676896924019&w=2\n[10]http://article.gmane.org/gmane.comp.version-control.git/88724/match=gitmodules\n[11]\n\nThanks,\n\nP Baker\n"},{"id":"110267","messageId":"fabb9a1e0904022122w4b11dbccr69a48f08c6f345a4@mail.gmail.com","threadId":"18701","inReplyTo":"526944450904022015n67be674dwfab5d3dc597c806b@mail.gmail.com","subject":"Re: [RFC] GSoC Proposal v2:","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-04-03T04:22:29Z","receivedAt":"2009-04-03T04:22:29Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, Apr 3, 2009 at 05:15, P Baker <me@retrodict.com> wrote:\n> See below for a revised project application. More comments would be\n> appreciated. Thanks to Shawn, Dscho and Andreas for already offering\n> some help!\n\nIn case you haven't noticed the announcement, please submit your\nproposal for GSoC to http://socghop.appspot.com as soon as possible!\nThanks :).\n\n-- \nCheers,\n\nSverre Rabbelier\n"}]}