(cc-ing the git list; hoping that's okay.) Hi Thiago, Thiago Farina wrote: > Would you help me to find some ideas to work on git? I'd also be > interested in working in some API related to libgit2. I'm probably not a good bet for that, since I'm not familiar with libgit2 at all. You'd probably want to contact the libgit2 list at <libgit2@xxxxxxxxxxxxx>. Because of Google's summer program there's a list of potential projects at <https://git.wiki.kernel.org/index.php/SoC2011Ideas>. Some people were mentioning the possibility of keeping a list like this year-round, to give people something to hack on. I can help find a project in the field of merge, remote helpers, documentation processing, or startup procedure (repository discovery and option parsing). Or you can steal a project from me, if you'd like. Here's a few: - glibc: <http://sourceware.org/bugzilla/show_bug.cgi?id=6530>. This is desperately needed before translated output from the git cli becomes possible. - unifdef: split into coroutines following the stages of preprocessing described by the C standard, so it can handle more real-life preprocessor conditionals. This should help with understanding the #ifdef-ed mess that is glibc's printf (see above). - various git commands: support --patience, for patience diff. Make a simple test script to demonstrate that it's turned on. Especially nice would be "git add -p". http://bugs.debian.org/522361 - daemon: add some tests (using daemon --inetd, presumably). Let the client know when the repository is inaccessible: http://thread.gmane.org/gmane.comp.version-control.git/145456/focus=145573 - daemon: add an option to stop tolerating inability to listen on one of the supplied interfaces. Make a sysvinit / systemd / runit / whatever script describing best practices for running a persistent git daemon for contrib. - git test suite: find the remaining missing "&&"-s, fix them, and make future tests without them automatically fail. http://thread.gmane.org/gmane.comp.version-control.git/157903/focus=158265 - scripts: use "set -u" in git-sh-setup, and fix the errors that result. Some of the fixes won't be suitable for mainline: e.g. use of GIT_ variables would have to change to if test "${GIT_FOO:+set}" then ... use GIT_ variable ... fi to suppress the error, but I doubt mainline git wants it. Other fixes (protecting against the environment by initializing local variables to be empty) would be very much suitable for mainline. - contrib: make a Makefile so the invoker can install all the crazy contributed goodies at once if she wants to. - look for interesting (possibly old) patch series on the list (like the whole-directory-rename series!) and nudge them forward. Hope that helps, Jonathan -- 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