chore(3p/git): Unvendor git and track patches instead r/2903

This was vendored a long time ago under the expectation that keeping
it in sync with cgit would be easier this way, but it has proven not
to be a big issue.

On the other hand, a vendored copy of git is an annoying maintenance
burden. It is much easier to rebase the single (dottime) patch that we
have.

This removes the vendored copy of git and instead passes the git
source code to cgit via `pkgs.srcOnly`, which includes the applied
patch so that cgit can continue rendering dottime.

Change-Id: If31f62dea7ce688fd1b9050204e9378019775f2b

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