Greetings, I've been working on this for a while, but figured I'd send it out while I've still got some time left before I submit it! Any comments/questions would be welcome, as I'd really love to spend a summer working on git. Abstract: This project focuses on upgrading git-submodule to manage code created in external projects in ways that allow users to safely branch and merge that code without loss of data or routine merge conflicts. This will incorporate some changes made on the ‘pu’ branch, but will also include making substantial changes to git-submodule underlying code. Content: git-submodule is currently a good tool designed to allow developers to leverage the work of others by incorporating external code into a project. However, its implementation is underdeveloped as most core users/developers are not heavy users of the application. In contrast to much of the rest of the project, these holes create usage problems when git does not act according to developers’ expectations. This project would devote a summer of work to filling in the gaps so that git-submodules contains the features necessary to fully exploit its potential to track, update and edit external codebases incorporated into a super-project. As opposed to “remotes,” which also incorporate external code into a project, submodules maintain the distinct nature of code and separate the projects’ history. This is perfect for the intended nature of “embedding foreign repositories in dedicated subdirectories of the source tree.” For example, managing plug-ins within a larger, standalone project that depends on the plug-ins. However, the shortcomings of git-submodule create headaches for developers attempting to use git and might prevent its adoption among those developers not willing to either create laborious workarounds or explicitly create manual management techniques. Adding the features to fully enable git-submodule would allow heavy users of projects built on other actively developed projects to use git to manage this interaction in intuitive and predictable ways. Adding this feature set would give current users a desired tool, boost git’s credibility by providing a common feature among revision systems, make git’s adoption for new and existing projects easier and, as a result, likely boost git’s usage. This project will consist of several stages: an initial community based design review and investigation of specific requirements; specifying and documenting the planned changes; writing and debugging the code and related tests; and finally merging it into a public release. The tentative timeline is: End of May – Conclusively finish the public discussion regarding where git-submodules needs to go Beginning of June – Produce final specifications (including method stubs) Middle of July – Finish active code and test development End of July – Merge code into production release, fix public submitted bugs Middle of August – Prepare code for final release and finish user-facing documentation This timeline should allow adequate flexibility while establishing deadlines that ensure that the project will be completed in a timely and efficient manner. A few specific changes that this project will likely include are: *use .git instead of .gitmodules *move objects of submodules into .git/ directory *git submodule update --init should initialize nested levels of submodules *protect changes in local submodules when doing “git submodule update” These changes, compiled from feature requests on the git mailing list and formulated in response to blog posts regarding git-submodule’s issues, are representative of the full list of changes. Most development will need to occur within git-submodules.sh, without changing much plumbing, however, other files might be affected by more substantial changes. While git-submodule is stable and operational, it is not widely updated and has not seen much change beyond bug-fixes. After reaching its current feature complete status, the last time a feature of any novelty was included in a public release was August 2008. However, some work has already been started on the ‘pu’ branch, which will need to be reviewed and probably incorporated into this project. At the conclusion of the project, one metric by which to evaluate its success will be its acceptance in online communities. The final goal is to make git a top-tier version control system in its management of external code repositories. My main usage of git started when managing a summer project as an intern that had many of the requirements that make git-submodule problematic: built in Ruby on Rails and dependent on other plug-ins, some of which were managed in SVN. Even though the Ruby on Rails community has popularized within itself the use of sub-modules to manage plug-ins and quite a bit has been written on the topic, a significant portion end either in frustration or convoluted work-arounds. The problems and extremely confusing nature of git-submodule led me to give up on it altogether (an unfortunately common occurrence), and manage the code and updates to it by hand. I currently am finishing my sophomore year as an Electrical Engineer at the University of Pennsylvania (and dual-majoring in the Wharton School of Business). I started to develop professionally when I took a year off between high school and college to work for a small firm in Silicon Valley, California developing diagnostic imaging software for quality assurance and research on their products. Last summer I developed an Ruby on Rails-based engine to test user-designed investment strategies for QED Benchmark, a boutique hedge fund. Thanks, Phill Baker -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
