Hi, On Wed, 17 Oct 2018 at 14:05:27 +0200, Eike Rathke wrote:
On Wednesday, 2018-10-17 04:27:54 +0200, Guilhem Moulin wrote:* diff: https://gerrit.libreoffice.org/plugins/gitiles/core/+/master%5E%21/ vs. https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=refs/heads/masterFor diffs I much prefer the gerrit view because it highlights changes within changed lines, for example https://gerrit.libreoffice.org/plugins/gitiles/core/+/9672d034b9e760f24ac9a6652ab45dee15ee260a%5E%21/ vs https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=9672d034b9e760f24ac9a6652ab45dee15ee260a Would that be possible also with gitiles?
Not that I know of, and looking at the source I don't think so
https://gerrit.googlesource.com/gitiles/+/master/java/com/google/gitiles/HtmlDiffFormatter.java#142
There is a feature request for a side-by-side view in Gitiles (mimicking
the gerrit view), which I assume includes change highlighting; no update
there, though: https://code.google.com/archive/p/gitiles/issues/2 .
Lastly, it's now possible to clone and fetch git repositories over https:// . While git:// URLs will remain supported for the foreseeable future, they're intentionally no longer advertised in gerrit, and we encourage you to upgrade the scheme of your ‘remote.<name>.url’ to secure transports (SSH for authenticated access, or HTTPS for anonymous access). We'll update ‘lode’ and chase remaining git:// URLs shortly.Why is git:// deprecated? From what I know it's more efficient when fetching/pulling than https:// (or ssh://?)
Since v1.6.6 it's no longer true [0], cf. git-http-backend(1) and https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes . We're using the so-called “smart” HTTP protocol, with a git-upload-pack(1) service on the server. SSH is only used for transport, a git processed is exec()'ed on the remote just like for git-daemon(1), so the only overhead is crypto-related. The handshake is a one-off thing, thus negligible when you're transferring a large amount of data at once; and if you're connecting so often to an SSH remote that the handshake undermines performance, you should probably activate connection multiplexing in your client, cf. ssh_config(5) :-) As for symmetric crypto overhead, these days everyone has CPUs with AES-NI instructions (at least on build machines), hence the overhead should be negligible. Cheers, -- Guilhem. [0] https://github.com/git/git/blob/master/Documentation/RelNotes/1.6.6.txt
Attachment:
signature.asc
Description: PGP signature