diff options
Diffstat (limited to 'third_party/git/contrib/README')
| -rw-r--r-- | third_party/git/contrib/README | 43 |
1 files changed, 0 insertions, 43 deletions
diff --git a/third_party/git/contrib/README b/third_party/git/contrib/README deleted file mode 100644 index 05f291c1f1d3..000000000000 --- a/third_party/git/contrib/README +++ /dev/null @@ -1,43 +0,0 @@ -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 |