Re: git: ideas and libgit2

Re: git: ideas and libgit2

[Jonathan Nieder]

(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@librelist.org>.

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