|  | Contributed Software | 
|  |  | 
|  | Although these pieces are available as part of the official git | 
|  | source tree, they are in somewhat different status.  The | 
|  | intention is to keep interesting tools around git here, maybe | 
|  | even experimental ones, to give users an easier access to them, | 
|  | and to give tools wider exposure, so that they can be improved | 
|  | faster. | 
|  |  | 
|  | I am not expecting to touch these myself that much.  As far as | 
|  | my day-to-day operation is concerned, these subdirectories are | 
|  | owned by their respective primary authors.  I am willing to help | 
|  | if users of these components and the contrib/ subtree "owners" | 
|  | have technical/design issues to resolve, but the initiative to | 
|  | fix and/or enhance things _must_ be on the side of the subtree | 
|  | owners.  IOW, I won't be actively looking for bugs and rooms for | 
|  | enhancements in them as the git maintainer -- I may only do so | 
|  | just as one of the users when I want to scratch my own itch.  If | 
|  | you have patches to things in contrib/ area, the patch should be | 
|  | first sent to the primary author, and then the primary author | 
|  | should ack and forward it to me (git pull request is nicer). | 
|  | This is the same way as how I have been treating gitk, and to a | 
|  | lesser degree various foreign SCM interfaces, so you know the | 
|  | drill. | 
|  |  | 
|  | I expect that things that start their life in the contrib/ area | 
|  | to graduate out of contrib/ once they mature, either by becoming | 
|  | projects on their own, or moving to the toplevel directory.  On | 
|  | the other hand, I expect I'll be proposing removal of disused | 
|  | and inactive ones from time to time. | 
|  |  | 
|  | If you have new things to add to this area, please first propose | 
|  | it on the git mailing list, and after a list discussion proves | 
|  | there are some general interests (it does not have to be a | 
|  | list-wide consensus for a tool targeted to a relatively narrow | 
|  | audience -- for example I do not work with projects whose | 
|  | upstream is svn, so I have no use for git-svn myself, but it is | 
|  | of general interest for people who need to interoperate with SVN | 
|  | repositories in a way git-svn works better than git-svnimport), | 
|  | submit a patch to create a subdirectory of contrib/ and put your | 
|  | stuff there. | 
|  |  | 
|  | -jc |