On Tue, Feb 5, 2013 at 5:03 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Do you have any plans for something that *does* have the reduction of
>> network bandwidth as a primary goal?
>
> Uncluttering gives reduction of bandwidth anyway, so I do not see
> much point in the dist
Ævar Arnfjörð Bjarmason writes:
> Do you have any plans for something that *does* have the reduction of
> network bandwidth as a primary goal?
Uncluttering gives reduction of bandwidth anyway, so I do not see
much point in the distinction you seem to be making.
> Is this what you've been workin
On Wed, Jan 30, 2013 at 7:45 PM, Junio C Hamano wrote:
> The third round.
>
> - Multi-valued variable transfer.hiderefs lists prefixes of ref
>hierarchies to be hidden from the requests coming over the
>network.
>
> - A configuration optionally allows uploadpack to accept fetch
>requ
On Wed, Oct 10, 2012 at 6:44 PM, Nguyen Thai Ngoc Duy wrote:
> On Thu, Oct 11, 2012 at 3:46 AM, Junio C Hamano wrote:
>> Steffen Prohaska writes:
>>
>>> I've recently discovered that the current protocol can be amazingly
>>> inefficient when it comes to transferring binary objects. Assuming two
On Thu, Oct 11, 2012 at 3:46 AM, Junio C Hamano wrote:
> Steffen Prohaska writes:
>
>> I've recently discovered that the current protocol can be amazingly
>> inefficient when it comes to transferring binary objects. Assuming two
>> repositories that are in sync. After a 'git checkout --orphan &
From: "Junio C Hamano"
Steffen Prohaska writes:
I've recently discovered that the current protocol can be amazingly
inefficient when it comes to transferring binary objects. Assuming
two
repositories that are in sync. After a 'git checkout --orphan && git
commit', a subsequent transfers s
Steffen Prohaska writes:
> I've recently discovered that the current protocol can be amazingly
> inefficient when it comes to transferring binary objects. Assuming two
> repositories that are in sync. After a 'git checkout --orphan && git
> commit', a subsequent transfers sends all the blobs at
On Oct 8, 2012, at 6:27 PM, Junio C Hamano wrote:
> Once we go into "want/have" phase, I do not think there is a need
> for fundamental change in the protocol (by this, I am not counting a
> change to send "have"s sparsely and possibly backtracking to bisect
> history, etc. as "fundamental").
I'v
Andreas Ericsson writes:
> You'll want that to be a single "wants" message to avoid incurring
> insane amounts of roundtrip latency with lots of refs. github and
> other hosted services are quite popular, but with my 120ms ping
> rtt I'd be spending half a minute just telling the other side what
On 10/07/2012 09:57 PM, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> I'm creating a system where a lot of remotes constantly fetch from a
>>> central repository for deployment purposes, but I've noticed that even
Ævar Arnfjörð Bjarmason writes:
> On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> I'm creating a system where a lot of remotes constantly fetch from a
>>> central repository for deployment purposes, but I've noticed that even
>>> with a remote.$na
On Sun, Oct 07, 2012 at 09:57:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Has anyone started working on a next-gen Git protocol as a result of
> this discussion? If not I thought I'd give it a shot if/when I have
> time.
I haven't, and don't really plan on it soon (I have a few smaller things
I'
On Sun, Oct 07, 2012 at 09:57:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> Has anyone started working on a next-gen Git protocol as a result of
> this discussion? If not I thought I'd give it a shot if/when I have
> time.
Unfortunately, client signaling the version is nasty to do in ways that
w
On Wed, Oct 3, 2012 at 9:13 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> I'm creating a system where a lot of remotes constantly fetch from a
>> central repository for deployment purposes, but I've noticed that even
>> with a remote.$name.fetch configuration to only get certai
14 matches
Mail list logo
