[TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

[Guilhem Moulin]

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/master
> 
> For 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20181017/a2f40eba/attachment.sig>