On Tue, Jul 19, 2016 at 02:33:09PM -0700, Junio C Hamano wrote:
> > Git writes --> 4 byte content length
> > Git writes --> content string
> > Git reads <-- 4 byte filtered content length
> > Git reads <-- filtered content
>
> Do you really need to force the sender to know the length in
> advance
> On 20 Jul 2016, at 10:59, Jakub Narębski wrote:
>
> W dniu 2016-07-19 o 23:33, Junio C Hamano pisze:
>> Lars Schneider writes:
>>
Git writes --> 4 byte filename length
Git writes --> filename string
>>
>> Why limit to 32GB? Perhaps NUL termination is more appropriate
>> here?
>
W dniu 2016-07-19 o 23:33, Junio C Hamano pisze:
> Lars Schneider writes:
>
>> > Git writes --> 4 byte filename length
>> > Git writes --> filename string
>
> Why limit to 32GB? Perhaps NUL termination is more appropriate
> here?
Errr, I think limiting _filename_ to 32GB is a reasonable
assumpt
On 07/20/2016 12:01 AM, Lars Schneider wrote:
On 19 Jul 2016, at 23:33, Junio C Hamano wrote:
Lars Schneider writes:
Git writes --> 4 byte filename length
Git writes --> filename string
Why limit to 32GB? Perhaps NUL termination is more appropriate
here?
OK, I will use NUL terminatio
On 19 Jul 2016, at 23:33, Junio C Hamano wrote:
> Lars Schneider writes:
>
>> Git writes --> 4 byte filename length
>> Git writes --> filename string
>
> Why limit to 32GB? Perhaps NUL termination is more appropriate
> here?
OK, I will use NUL termination for the filename.
You're also right
Lars Schneider writes:
> Git writes --> 4 byte filename length
> Git writes --> filename string
Why limit to 32GB? Perhaps NUL termination is more appropriate
here?
> Git writes --> 4 byte content length
> Git writes --> content string
> Git reads <-- 4 byte filtered content length
> Git reads
On 19 Jul 2016, at 20:53, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> The key benefit of this arrangement is the above can be done without
>> having to do poll() to flip between reading and writing that is
>> needed to avoid deadlocking, which kept the code simpler. A later
>> convers
Junio C Hamano writes:
> The key benefit of this arrangement is the above can be done without
> having to do poll() to flip between reading and writing that is
> needed to avoid deadlocking, which kept the code simpler. A later
> conversion of the write side into async does not fundamentally
> c
Lars Schneider writes:
> a long time ago in aa4ed4 Junio introduced the external filter
> driver definition. Since that time we fork the Git process and
> then we fork again to run the external filter. This is probably a
> super stupid question with an obvious answer... but can anyone
> help me t
Hi,
a long time ago in aa4ed4 Junio introduced the external filter driver
definition. Since that time we fork the Git process and then we fork again to
run the external filter. This is probably a super stupid question with an
obvious answer... but can anyone help me to understand the code and e
10 matches
Mail list logo
