Git    

Restartable git clone    

Currently, in case git clone fails throughout the operation, all the work performed so far and data downloaded are scrapped and the user has to start again from scratch. It would be good to have a way to resume git clone in case of e.g. interrupted download.

Smart fetch/push over HTTP    

Currently, Git can fetch over plain HTTP, however this way of fetching is very inefficient and the repository has to be specially configured for this. It can also push over HTTP DAV, but that's just plain hairy.

How about smart fetch/push over HTTP? E.g. a CGI (or extension to gitweb) that does native pack transport over HTTP rather than dumb object traversal with GET and WebDAV LOCK/PUT. Note that the push side doesn't need to support tell-me-more extension, making it a fairly trivial GET, POST (or PUT) sequence.

Suggested by spearce.

git daemon zeroconf advertisement    

It might be cool if git-daemon supported
avahi/zeroconf/bonjour/rendezvous as a server and maybe some way to list repositories on the local network being advertised over avahi.

It looks like bzr has an avahi plugin. Not sure whether it would be a useful feature for people. What do other folks think?

Suggested by Tarmigan.

gitweb enhancements    

The gitweb web frontend for Git could use bunch of improvements - to accommodate for the given format, this mix might do:

* syntax highlighting support for files (blobs) browsing

* support for special keywords in commit messages (e.g. making /bug (\d+)/ a Bugzilla link)

* optionally showing file size / last commit modifying a file in the web interface

* and most importantly, builtin support for displaying project history in a graphical tree

(picked from Jakub Narebski's gitweb wishlist summary)

Support for visual pickaxe frontend    

Pickaxe is a mechanism to search the history for commits that added/removed/modified a particular string (be it adding a call to a function or changing body of some statement) - think of it as much more flexible kind of the classical "blame" operation.

Currently, you can invoke this Git feature using git log -S or by typing the searched-for string within gitweb, which is not so practical, especially for the latter case of tracing the movement of a larger chunk of code; the users usually opt for a clumsy way of examining git blame output (which is very smart about the movement anyway, though). The goal would be to implement a simple graphical frontend for pickaxe: you would select a particular code block within file by mouse and the group would present you with an overview of the code evolution and possibly movement.

(I have such a tool in my pipeline as work-in-progress; in case I will reach any releasable state, there will be certainly still plenty of work to do, though: Implementing support for properly tracking code movement between files, combination with the blame function or comparing files or file versions side-by-side, various visualization techniques, etc.)

This could become a quite ground-breaking tool for fast and convenient history examination.

Support for FTP and SFTP transports    

It would be nice to be able to push/pull over FTP and SFTP as dumb protocols.

git merge-blame merging strategy    

Git can figure out movement of pieces of code across files throughout the code history, but currently cannot apply this information for auto-resolving conflicts during a merge. This project would teach Git that.

Further information

Implement narrow checkout    

Sometimes, it is useful to check out only part of the source tree, especially if the whole tree is very big. This could be elegantly implemented using the "assume unchanged" index bit; testing how all the common commands cope with this and writing a good testsuite for this feature would be probably a large part of the task.

SSL support for git-daemon    

Currently, the native git transfer (git-daemon-driven) is unencrypted. Support for SSL/TLS encryption might be useful.

Relative blame    

Relative blame, i.e. if you have blame data for some revision (for example in "git gui blame") you want to have data for some revision which is either direct ancestor or direct descendant of the revision you have blame data for, aka "git blame --relative". Suggested by Jakub Narebski.

Better support for git log tracking files over renames    

Improvements to "git log --follow" so it works also for nonlinear history (for example "git log --follow gitweb/gitweb.perl" following to the very first version of gitweb, then as gitweb.cgi). Suggested by Jakub Narebski.

Graphical history in Emacs-Git    

Gaphical history viewer for Git mode in Emacs. Suggested by Jakub Narebski.

Custom merge strategy suite    

Custom merge strategy for ChangeLog, for .po files and possibly other interesting file formats that have special structure and tend to provoke a lot of spurious conflicts.