Table of Contents:
Git plans to apply for the Google Summer of Code 2010. Although we have not been accepted yet, here are a few interesting projects:
Projects touching the core of Git
Git Fetch/Clone Mirror Support
Git automatic mirroring is a system for making Git repositories distribute automatically. It is the first stage of more general P2P features planned. The idea is that when fetching data from a server, the server can inform the client of mirrors of the repository, which the client can fetch the majority of the data from, then fetch any remaining objects from the main server. This way large Git projects can be served from local mirrors for distributed teams, or large hosts such as git.kernel.org or github can effectively offload bandwidth to closer or more lightly loaded servers.
More details of the proposed updates here (copied from a Google wave page on the subject) : http://gist.github.com/301798
Goal: Allow Git fetch (client) and upload-pack (server) commands to list and partially fetch from mirror servers.
Possible Mentors: Scott Chacon / Sam Vilain
git sequencer again
There was a "git sequencer" GSoC 2008 project, the student was Stephan Beyer and the mentors were Christian Couder and Daniel Barkalow. This project came up with some working code but it did not get merged.
The goal of this project is to take some features, ideas and/or code from the former git sequencer project and other related efforts by Christian Couder to port "rebase -i" to C, and to step by step get them properly integrated and merged into Git mainline.
One intermediate step could be to have something like "git cherry-pick A..B" that many people have asked for.
Goal: Get some git sequencer related features properly merged.
Mentor: Christian Couder
Add-ons to Git
Merge helper for LaTeX files
Not everything tracked by Git is source code for programs; Git is actually a fantastic tool to collaborate on writing documents in LaTeX format.
Unfortunately, the merge conflicts created by Git's recursive merge are better suited for C code than for LaTeX, as the latter is frequently written such that a single line will produce a whole paragraph.
Therefore, a tool is needed which uses Git's output to present the differences between the two differing versions and the base version in a nice way. The tool should also offer an easy method to pick one version over the other, and to edit the result (and still show the three versions, pointing to the position corresponding to the current cursor position).
Goal: Provide a graphical tool to help with merge conflicts specifically in LaTeX files.
Language: As preferred by the student, but it should be portable between Linux, MacOSX and Windows.
Mentor: Johannes Schindelin
A remote helper for svn
Since the 1.6.6 release git has support for 'remote helpers'. These are standalone programs that allow git to talk to foreign scm's. On the other side, git has had support for 'git-svn' for quite a while now, providing (somewhat clumsy) support for working with svn repositories with git.
In order to make working with svn repositories as easy as working with regular git repositories, a new remote helper needs to be written that will bridge between svn and git. This can be done either by rewriting the current 'git svn' code (which is written in perl, and somewhat arcane), or by creating a helper from scratch, possibly using the svn bindings directly (although that might result in licensing conflicts).
Implementing a remote helper is fairly simple, it can be as simple as hooking up an implementation of fast-export and fast-import for the target source. Doing so has a lot of advantages though, since it allows users to natively access the other vcs. That is, at the end of the project, 'git clone svn://example.com' will Just Work. Remote helpers can be implemented in any language (as long as they speak the already defined 'remote-helper' protocol), but unless there is a very compelling reason not to, should be implemented in C, perl, or python.
Goal: Create a remote-helper for svn.
Language: C (preferred), perl, or python.
Mentor: Sverre Rabbelier
Git's source code was not written to be reentrant, but to execute a program doing a specific task, and then exit. This is not really useful if you want to access a Git repository using a library rather than executing a program, catching and parsing its output. Further, some companies seem to be put off by the GPL that applies to Git's source code, and would prefer a BSD licensed library to base their product on.
Shawn Pearce already started libgit2, but as of now most functions are not implemented. This project's purpose is to implement most of these functions, and maybe provide language bindings for Python, Ruby, etc.
"Goal": Implement enough of libgit2 to access a Git repository from a C program and/or a Python/Ruby/Whatever script.
"Language": C, doxygen
"Possible Mentors": Andreas Ericsson (email@example.com)
"Suggested By": Scott Chacon
Content History Browser
There is plenty of various visual commit history browsers, but little has been tried yet with regards to the really innovative stuff Git allows thanks to its speedy history access, and what has been envisioned at the dawn of some of Git's basic design choices. This project should try to create a graphical interface where the content is the primary object (instead of the commits) and that allows to easily visually follow history of certain content fragment (simply mouse selection, or auto-selection of certain code block, ...): how it moved within a single file and between files, when did it appear, who changed the code block in which way.
Petr Baudis already implemented a simple proof-of-concept tool giddy, however it stopped at providing trivial point-and-click pickaxe interface and visualizing diffs within the file; it cannot visualize the fragment's "path" through history or follow it across changes within the fragment. Giddy might be used as a base for this project, or the implementation could start from scratch. The project will involve combination of routine GUI development, smart UI design and research of proper heuristics to allow compensation against changes within the fragment.
Goal: Graphical application allowing to easily select a content fragment and visualize its history and movement even through smaller changes within the fragment.
Language: Reasonably portable with low startup time; ideally C/C++/Perl/Python.
Possible Mentor: Petr Baudis
An implementation of Git's recursive merge in JGit
The recursive merge algorithm is surprisingly powerful for its simplicity. A few fine points have to be taken care of, though, such as rename detection and file/directory conflicts.
The basic building block, however, is a diff algorithm, and JGit recently got its own implementation of that.
An implementation of the recursive merge will allow easy implementation of cherry-pick, and consequently of rebase -i, too.
Goal: Implement the recursive merge algorithm in JGit.
Mentor: Johannes Schindelin