[PATCH v2 01/17] contrib: remove outdated README

[Felipe Contreras <felipe.contreras@gmail.com>]

There is no guideline as for what should be part of contrib.

Some tools are actively maintained, others consist of a single commit.
Some tools have active user-base, some aren't used by anyone. Some tools
are on the path towards the core, others will never get there. Some
tools are already out-of-tree and simply mirrored, others probably
wouldn't survive out-of-tree. Some tools are production-ready, others
don't even run. Some tools have tests, most don't.

Junio has explained that he wrote this a long time ago, when Git was a
different beast, now this no longer applies.

The only way to find out if a tool belongs in contrib or not is to as
Junio.

Cc: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 contrib/README | 43 -------------------------------------------
 1 file changed, 43 deletions(-)
 delete mode 100644 contrib/README

diff --git a/contrib/README b/contrib/README
deleted file mode 100644
index 05f291c..0000000
--- a/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
-- 
1.9.2+fc1.28.g12374c0