path: root/contrib/persistent-https
AgeCommit message (Collapse)Author
2017-06-01docs/config: mention protocol implications of url.insteadOfJeff King
If a URL rewrite switches the protocol to something nonstandard (like "persistent-https" for "https"), the user may be bitten by the fact that the default protocol restrictions are different between the two. Let's drop a note in insteadOf that points the user in the right direction. It would be nice if we could make this work out of the box, but we can't without knowing the security implications of the user's rewrite. Only the documentation for a particular remote helper can advise one way or the other. Since we do include the persistent-https helper in contrib/ (and since it was the helper in the real-world case that inspired that patch), let's also drop a note there. Suggested-by: Elliott Cable <> Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-07-22contrib/persistent-https: use Git version for build labelParker Moore
The previous method simply used the UNIX timestamp of when the binary was built as its build label. $ make && ./git-remote-persistent-http -print_label 1469061546 This patch aims to align the label for this binary with the Git version contained in the GIT-VERSION-FILE. This gives a better sense of the version of the binary as it can be mapped to a particular revision or release of Git itself. For example: $ make && ./git-remote-persistent-http -print_label Discussion of this patch is available on a related thread in the mailing list surrounding this package called "contrib/persistent-https: update ldflags syntax for Go 1.7+". The link is: Signed-off-by: Parker Moore <> Signed-off-by: Junio C Hamano <>
2016-07-22contrib/persistent-https: update ldflags syntax for Go 1.7+Parker Moore
Running `make all` in `contrib/persistent-https` results in a failure on Go 1.7 and above. Specifically, the error is: go build -o git-remote-persistent-https \ -ldflags "-X main._BUILD_EMBED_LABEL 1468613136" # _/Users/parkr/github/git/contrib/persistent-https /usr/local/Cellar/go/1.7rc1/libexec/pkg/tool/darwin_amd64/link: -X flag requires argument of the form make: *** [git-remote-persistent-https] Error 2 This `name=value` syntax for the -X flag was introduced in Go v1.5 (released Aug 19, 2015): - release notes: - commit: In Go v1.7, support for the old syntax was removed: - release notes: - commit: Add '=' between the symbol and its value for recent versions of Go, while leaving it out for older ones. Signed-off-by: Parker Moore <> Signed-off-by: Junio C Hamano <>
2012-05-30Add persistent-https to contribColby Ranger
Git over HTTPS has a high request startup latency, since the SSL negotiation can take up to a second. In order to reduce this latency, connections should be left open to the Git server across requests (or invocations of the git commandline). Reduce SSL startup latency by running a daemon job that keeps connections open to a Git server. The daemon job (git-remote-persistent-https--proxy) is started on the first request through the client binary (git-remote-persistent-https) and remains running for 24 hours after the last request, or until a new daemon binary is placed in the PATH. The client determines the daemon's HTTP address by communicating over a UNIX socket with the daemon. From there, the rest of the Git protocol work is delegated to the "git-remote-http" binary, with the environment's http_proxy set to the daemon. Accessing /pub/scm/linux/kernel/git/torvalds/linux repository hosted at with "git ls-remote" over https:// and persistent-https:// 5 times shows that the first request takes about the same time (0.193s vs 0.208s---there is a slight set-up cost for the local proxy); as expected, the other four requests are much faster (~0.18s vs ~0.08s). Incidentally, this also has the benefit of HTTP keep-alive working across Git command invocations. Its common for servers to use a 5 minute keep-alive on an HTTP 1.1 connection. Git-over-HTTP commonly uses Transfer-Encoding: chunked on replies, so keep-alive will generally just work, even though a pack stream's length isn't known in advance. Because the helper is an external process holding that connection open, we also benefit from being able to reuse an existing TCP connection to the server. The same "git ls-remote" test against http:// vs persistent-https:// URL shows that the former takes ~0.09s while the first request for the latter is about 0.134s with set-up cost, and subsequent requests are ~0.065s, shaving around one RTT to the server. Signed-off-by: Colby Ranger <> Signed-off-by: Junio C Hamano <>