diff options
Diffstat (limited to 'contrib/README')
| -rw-r--r-- | contrib/README | 43 |
1 files changed, 43 insertions, 0 deletions
diff --git a/contrib/README b/contrib/README new file mode 100644 index 0000000..21d3d0e --- /dev/null +++ b/contrib/README @@ -0,0 +1,43 @@ +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 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 is general interest (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 |