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, 65 deletions

diff --git a/third_party/git/Documentation/RelNotes/2.5.1.txt b/third_party/git/Documentation/RelNotes/2.5.1.txt
deleted file mode 100644
index b70553308af8..000000000000
--- a/third_party/git/Documentation/RelNotes/2.5.1.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Git v2.5.1 Release Notes
-========================
-
-Fixes since v2.5
-----------------
-
- * Running an aliased command from a subdirectory when the .git thing
-   in the working tree is a gitfile pointing elsewhere did not work.
-
- * Often a fast-import stream builds a new commit on top of the
-   previous commit it built, and it often unconditionally emits a
-   "from" command to specify the first parent, which can be omitted in
-   such a case.  This caused fast-import to forget the tree of the
-   previous commit and then re-read it from scratch, which was
-   inefficient.  Optimize for this common case.
-
- * The "rev-parse --parseopt" mode parsed the option specification
-   and the argument hint in a strange way to allow '=' and other
-   special characters in the option name while forbidding them from
-   the argument hint.  This made it impossible to define an option
-   like "--pair <key>=<value>" with "pair=key=value" specification,
-   which instead would have defined a "--pair=key <value>" option.
-
- * A "rebase" replays changes of the local branch on top of something
-   else, as such they are placed in stage #3 and referred to as
-   "theirs", while the changes in the new base, typically a foreign
-   work, are placed in stage #2 and referred to as "ours".  Clarify
-   the "checkout --ours/--theirs".
-
- * An experimental "untracked cache" feature used uname(2) in a
-   slightly unportable way.
-
- * "sparse checkout" misbehaved for a path that is excluded from the
-   checkout when switching between branches that differ at the path.
-
- * The low-level "git send-pack" did not honor 'user.signingkey'
-   configuration variable when sending a signed-push.
-
- * An attempt to delete a ref by pushing into a repository whose HEAD
-   symbolic reference points at an unborn branch that cannot be
-   created due to ref D/F conflict (e.g. refs/heads/a/b exists, HEAD
-   points at refs/heads/a) failed.
-
- * "git subtree" (in contrib/) depended on "git log" output to be
-   stable, which was a no-no.  Apply a workaround to force a
-   particular date format.
-
- * "git clone $URL" in recent releases of Git contains a regression in
-   the code that invents a new repository name incorrectly based on
-   the $URL.  This has been corrected.
-   (merge db2e220 jk/guess-repo-name-regression-fix later to maint).
-
- * Running tests with the "-x" option to make them verbose had some
-   unpleasant interactions with other features of the test suite.
-   (merge 9b5fe78 jk/test-with-x later to maint).
-
- * "git pull" in recent releases of Git has a regression in the code
-   that allows custom path to the --upload-pack=<program>.  This has
-   been corrected.
-
- * pipe() emulation used in Git for Windows looked at a wrong variable
-   when checking for an error from an _open_osfhandle() call.
-
-Also contains typofixes, documentation updates and trivial code
-clean-ups.