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

diff --git a/third_party/git/Documentation/technical/packfile-uri.txt b/third_party/git/Documentation/technical/packfile-uri.txt
deleted file mode 100644
index 318713abc371..000000000000
--- a/third_party/git/Documentation/technical/packfile-uri.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-Packfile URIs
-=============
-
-This feature allows servers to serve part of their packfile response as URIs.
-This allows server designs that improve scalability in bandwidth and CPU usage
-(for example, by serving some data through a CDN), and (in the future) provides
-some measure of resumability to clients.
-
-This feature is available only in protocol version 2.
-
-Protocol
---------
-
-The server advertises the `packfile-uris` capability.
-
-If the client then communicates which protocols (HTTPS, etc.) it supports with
-a `packfile-uris` argument, the server MAY send a `packfile-uris` section
-directly before the `packfile` section (right after `wanted-refs` if it is
-sent) containing URIs of any of the given protocols. The URIs point to
-packfiles that use only features that the client has declared that it supports
-(e.g. ofs-delta and thin-pack). See protocol-v2.txt for the documentation of
-this section.
-
-Clients should then download and index all the given URIs (in addition to
-downloading and indexing the packfile given in the `packfile` section of the
-response) before performing the connectivity check.
-
-Server design
--------------
-
-The server can be trivially made compatible with the proposed protocol by
-having it advertise `packfile-uris`, tolerating the client sending
-`packfile-uris`, and never sending any `packfile-uris` section. But we should
-include some sort of non-trivial implementation in the Minimum Viable Product,
-at least so that we can test the client.
-
-This is the implementation: a feature, marked experimental, that allows the
-server to be configured by one or more `uploadpack.blobPackfileUri=<sha1>
-<uri>` entries. Whenever the list of objects to be sent is assembled, all such
-blobs are excluded, replaced with URIs. The client will download those URIs,
-expecting them to each point to packfiles containing single blobs.
-
-Client design
--------------
-
-The client has a config variable `fetch.uriprotocols` that determines which
-protocols the end user is willing to use. By default, this is empty.
-
-When the client downloads the given URIs, it should store them with "keep"
-files, just like it does with the packfile in the `packfile` section. These
-additional "keep" files can only be removed after the refs have been updated -
-just like the "keep" file for the packfile in the `packfile` section.
-
-The division of work (initial fetch + additional URIs) introduces convenient
-points for resumption of an interrupted clone - such resumption can be done
-after the Minimum Viable Product (see "Future work").
-
-Future work
------------
-
-The protocol design allows some evolution of the server and client without any
-need for protocol changes, so only a small-scoped design is included here to
-form the MVP. For example, the following can be done:
-
- * On the server, more sophisticated means of excluding objects (e.g. by
-   specifying a commit to represent that commit and all objects that it
-   references).
- * On the client, resumption of clone. If a clone is interrupted, information
-   could be recorded in the repository's config and a "clone-resume" command
-   can resume the clone in progress. (Resumption of subsequent fetches is more
-   difficult because that must deal with the user wanting to use the repository
-   even after the fetch was interrupted.)
-
-There are some possible features that will require a change in protocol:
-
- * Additional HTTP headers (e.g. authentication)
- * Byte range support
- * Different file formats referenced by URIs (e.g. raw object)