Re: Getting started contributing.

From: "Junio C Hamano" <redacted>
Sent: Sunday, February 03, 2013 7:49 AM

adamfraser [off-list ref] writes:

quoted

I've done a little searching and
haven't been able to find an official bug tracker for git is there 
somewhere
I can find some bugs to help fix?

You came to the right place.  A new bug or regression is reported to
this list, and it often is fixed (or often diagnosed as pebcak)
fairly quickly by list regulars.  Nobody maintains a bugzilla that
is not maintained and is full of stale/invalid bug reports.

The best contribution a new person can make is to use the software
regularly and find issues.  It is very hard to find real bugs that
can easily be fixed by somebody totally new to the codebase in Git
these days.

On the other hand, there probably still are many loose ends.  When a
command is supposed to take only two arguments because taking more
than three does not make any sense, for example, it has not been
unusual for us to document the two-argument form of the command,
reject if the user gives only one argument with an error message,
but we simply ignore the third argument if the user mistakenly runs
the command with three arguments, instead of erroring out (i.e. the
code does not bother to help insane or too inexperienced users).
That kind of things are hard to find by users experienced with Git
exactly because they know running such a command with three or more
arguments is nonsense, and they do not even try to make such a
mistake.  Still, it would be very nice to find and fix such issues.

A review of the git-user list 
https://groups.google.com/forum/?fromgroups#!forum/git-users is one 
place to discover some of the user issues and thinking about how to 
address them. Or resurrect issues from this Git list. E.g. There are a 
number of sub-module improvements available there.

If you have any Windows experience the MSysGit team 
https://github.com/msysgit/msysgit is always looking for help on some of 
the compatibility issues, e.g. where the Linux optimisations conflict 
with the Windows approaches.

Another area is picking out documentation issues you have seen and 
submitting patches for them, whether in the command man pages or in the 
guides. On my 'todo' list is to make the `help` command actually list 
the "Help me" (i.e. guides and articles) pages, not just the command man 
pages.

I also had -
* Bulk move detection (when folk change/move upper level directory 
names).
* add a .gitnevermerge option to stop private files you don't want in 
'master' (or any other branch) to be merged

Philip