kernel/git - git - PowerEL Git System

57223 Commits

6 Branches

36 Tags

131 MiB

Tree: 566a1439f6

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
Parker Moore	accb613afd	contrib/persistent-https: use Git version for build label 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 2.9.1.275.g75676c8 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 gmane.org link is: http://article.gmane.org/gmane.comp.version-control.git/299653/ Signed-off-by: Parker Moore <parkrmoore@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Parker Moore	dbd1294401	contrib/persistent-https: update ldflags syntax for Go 1.7+ 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 importpath.name=value 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: https://golang.org/doc/go1.5#link - commit: `12795c02f3` In Go v1.7, support for the old syntax was removed: - release notes: https://tip.golang.org/doc/go1.7#compiler - commit: `51b624e6a2` Add '=' between the symbol and its value for recent versions of Go, while leaving it out for older ones. Signed-off-by: Parker Moore <parkrmoore@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Colby Ranger	fe0435011c	Add persistent-https to contrib 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 kernel.googlesource.com 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 <cranger@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago

Parker Moore

accb613afd

contrib/persistent-https: use Git version for build label

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
    2.9.1.275.g75676c8

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 gmane.org link is:
http://article.gmane.org/gmane.comp.version-control.git/299653/

Signed-off-by: Parker Moore <parkrmoore@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

9 years ago

Parker Moore

dbd1294401

contrib/persistent-https: update ldflags syntax for Go 1.7+

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 importpath.name=value
    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: https://golang.org/doc/go1.5#link
 - commit: 12795c02f3

In Go v1.7, support for the old syntax was removed:

 - release notes: https://tip.golang.org/doc/go1.7#compiler
 - commit: 51b624e6a2

Add '=' between the symbol and its value for recent versions of Go,
while leaving it out for older ones.

Signed-off-by: Parker Moore <parkrmoore@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

9 years ago

Colby Ranger

fe0435011c

Add persistent-https to contrib

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 kernel.googlesource.com 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 <cranger@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

13 years ago

3 Commits (566a1439f6f56c2171b8853ddbca0ad3f5098770)