Re: git instructions - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: git instructions
Date
Msg-id 041f90ef-f6b1-dc7e-4321-0f80a6ce2aa1@anastigmatix.net
Whole thread Raw
In response to git instructions  (Magnus Hagander <magnus@hagander.net>)
Responses Re: git instructions  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On 02/01/2018 10:54 AM, Magnus Hagander wrote:

> in saying that git:// is faster than https://. In fact, we have some
> reports and testing that https:// can be significantly faster (due to other
> reasons).
Can you elaborate on the other reasons? It occurs to me that there
might be cases in which each way works better.

From an experience about 3½ years ago[1], I drew a conclusion
(which may have been erroneous, or may have changed in newer
git releases) that the http protocol handler was not as bidirectional:
the client was less able to negotiate with the server exactly which
objects it already had and which were wanted, leaving the server to
send a needlessly large mass of stuff by default, whereas git-over-ssh
was able to negotiate a tiny minimal pack file to transfer.

My experience was in the context of keeping a local clone that was
shallow (the project repo had enormous history going back aeons,
of no use for me to test small patches on HEAD), and it seemed
possible that the cutoff points for the shallow history were among
the information that did not get effectively conveyed to the server
over http.

I have not tested that again lately, or with the postgresql repo.
I guess I could, without much trouble.

-Chap

[1]:
https://stackoverflow.com/questions/25954622/a-way-to-keep-a-shallow-git-clone-just-minimally-up-to-date


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Jsonb transform for pl/python
Next
From: Pavel Stehule
Date:
Subject: CALL stmt, ERROR: unrecognized node type: 113 bug