, and not necessarily the primary goal.
Do you have any plans for something that *does* have the reduction of
network bandwidth as a primary goal?
In October I asked if anyone was working on a next-gen Git protocol[3]
that would provide clients with the ability to specify what refs they
wanted. You replied
Ævar Arnfjörð Bjarmason ava...@gmail.com 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
On Tue, Feb 5, 2013 at 5:03 PM, Junio C Hamano gits...@pobox.com wrote:
Ævar Arnfjörð Bjarmason ava...@gmail.com 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
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 haves sparsely and possibly backtracking to bisect
history, etc. as fundamental).
I've
Steffen Prohaska proha...@zib.de 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
From: Junio C Hamano gits...@pobox.com
Steffen Prohaska proha...@zib.de 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
On Wed, Oct 10, 2012 at 6:44 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote:
On Thu, Oct 11, 2012 at 3:46 AM, Junio C Hamano gits...@pobox.com wrote:
Steffen Prohaska proha...@zib.de writes:
I've recently discovered that the current protocol can be amazingly
inefficient when it comes to
what the receiver
wants, even when the receiver is interested in getting updates from
only one of them, or worse yet, when the receiver is only trying to
peek the ref it is interested has been updated.
Has anyone started working on a next-gen Git protocol as a result of
this discussion
Andreas Ericsson a...@op5.se 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
is interested in getting updates from
only one of them, or worse yet, when the receiver is only trying to
peek the ref it is interested has been updated.
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
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
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'm
the receiver
wants, even when the receiver is interested in getting updates from
only one of them, or worse yet, when the receiver is only trying to
peek the ref it is interested has been updated.
Has anyone started working on a next-gen Git protocol as a result of
this discussion?
I
13 matches
Mail list logo
