Re: [PATCH v6 06/13] pkt-line: add functions to read/write flush terminated packet streams

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 25, 2016, 22:31 UTC
Message-ID: <xmqqvayojx9e.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kaVg40H-LeDtFfDYqDFDDbr+um3ZYj8oAaqGu+q6k5e+A@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

> So the API provided by these read/write functions is intended
> to move a huge chunks of data. And as it puts the data on the wire one
> packet after the other without the possibility to intervene and e.g. send
> a side channel progress bar update, I would question the design of this.

Hmph, I didn't think about it.

But shouldn't one be able to set up sideband and channel one such large transfer on one band, while multiplexing other payload on other bands?

> If I understand correctly this will be specifically  used for large
> files locally,
> so e.g. a file of 5 GB (such as a virtual machine tracked in Git), would
> require about 80k packets.

What is wrong about that? 4*80k = 320kB overhead for length fields to transfer 5GB worth of data? I do not think it is worth worrying about it.

But I am more surprised by seeing that "why not a single huge packet" suggestion immediately after you talked about "without the possibility to intervene". They do not seem to be remotely related; in fact, they are going into opposite directions.

Puzzled.