Re: git instructions

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: git instructions
Date: 2018-02-01 16:20:45
Message-ID: 041f90ef-f6b1-dc7e-4321-0f80a6ce2aa1@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2018-02-01 16:33:54 CALL stmt, ERROR: unrecognized node type: 113 bug
Previous Message Peter Eisentraut 2018-02-01 16:06:44 Re: Jsonb transform for pl/python