On Wed, 6 Jul 2016, Junio C Hamano wrote:
> Thanks; will apply with a miniscule fix.
>
> > - >8
> > Subject: sideband.c: small optimization of strbuf usage
> >
> > Signed-off-by: Nicolas Pitre
> > ...
> > @@ -97,7 +97,7 @@ int recv_sideband(const char *me, int in_stream, int out)
> > }
>
Nicolas Pitre writes:
> Here's a patch on top of it providing small optimizations.
Thanks; will apply with a miniscule fix.
> - >8
> Subject: sideband.c: small optimization of strbuf usage
>
> Signed-off-by: Nicolas Pitre
> ...
> @@ -97,7 +97,7 @@ int recv_sideband(const char *me, int in_s
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> > To make it clearer, here's a patch on top of pu that fixes all the
> > issues I think are remaining. All tests pass now.
>
> Lukas, can you see what is in 'pu' after I push out today's
> integration result in several hour
Lukas Fleischer writes:
> Oh, and one more detail: I wonder why we still use fwrite(), now that we
> know we can use xwrite() which guarantees atomicity. Is there a reason
> for that?
The code (before squashing anyway) used to use fprintf() directly
bypasing the outbuf for unusual cases, and we
On Wed, 29 Jun 2016 at 18:40:16, Junio C Hamano wrote:
> Lukas, can you see what is in 'pu' after I push out today's
> integration result in several hours and tell us if you like the
> result of the SQUASH??? change?
Looks good to me. Thank you both for working on this. Note that you
should amend
Nicolas Pitre writes:
> To make it clearer, here's a patch on top of pu that fixes all the
> issues I think are remaining. All tests pass now.
>
> diff --git a/sideband.c b/sideband.c
> index 36a032f..0e6c6df 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -23,10 +23,8 @@ int recv_sideband(con
On Tue, 28 Jun 2016, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > It's just that if you take the latter, then the conditional after
> > the loop exits (i.e. the last transmission was an incomplete line)
> > cannot be "is outbuf empty?", as your base state is "has PREFIX and
> > can never
Junio C Hamano writes:
> It's just that if you take the latter, then the conditional after
> the loop exits (i.e. the last transmission was an incomplete line)
> cannot be "is outbuf empty?", as your base state is "has PREFIX and
> can never be empty". I was working back from that if statement.
On Tue, 28 Jun 2016, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> >> The basic structure of the code (without the "SQUASH" we discussed)
> >> looks like this:
> >>
> >>strbuf_addf(&outbuf, "%s", PREFIX);
> >>while (retval == 0) {
> >>len = packet_read(in_stream, NULL, N
Junio C Hamano writes:
> But then my observation still holds, no?
>
> ...
> if (outbuf.len) {
> /* we still have something to say */
> strbuf_splice(&outbuf, 0, 0, PREFIX,
> strlen(PREFIX));
> fwrite(...);
> }
I guess thes
Nicolas Pitre writes:
>> The basic structure of the code (without the "SQUASH" we discussed)
>> looks like this:
>>
>> strbuf_addf(&outbuf, "%s", PREFIX);
>> while (retval == 0) {
>> len = packet_read(in_stream, NULL, NULL, buf, LARGE_PACKET_MAX,
>> 0);
>> ..
On Tue, 28 Jun 2016, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> >> There is something else going on. I cannot quite explain why I am
> >> getting this failure from t5401-update-hooks.sh, for example:
> >>
> >> --- expect 2016-06-28 19:46:24.564937075 +
> >> +++ actual
Nicolas Pitre writes:
>> There is something else going on. I cannot quite explain why I am
>> getting this failure from t5401-update-hooks.sh, for example:
>>
>> --- expect 2016-06-28 19:46:24.564937075 +
>> +++ actual 2016-06-28 19:46:24.564937075 +
>> @@ -9,3 +9,
On Tue, 28 Jun 2016, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> > Without this, the error and remaining buffer would be reversed as
> > mentioned previously. With this, the order is restored, but a newline
> > is added to unterminated lines whereas the error was simply appended to
> >
Nicolas Pitre writes:
> Without this, the error and remaining buffer would be reversed as
> mentioned previously. With this, the order is restored, but a newline
> is added to unterminated lines whereas the error was simply appended to
> the output before Lukas' patch.
>
> In any case the new
On Tue, 28 Jun 2016, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> >> When we exit the loop because we set retval to a non-zero value,
> >> should we still drain the outbuf?
> >
> > I would think so. Anything that the remote sent before any error should
> > be printed nevertheless. The cl
Nicolas Pitre writes:
>> When we exit the loop because we set retval to a non-zero value,
>> should we still drain the outbuf?
>
> I would think so. Anything that the remote sent before any error should
> be printed nevertheless. The clue for the error might be in the pending
> buffer.
>
> Ho
On Tue, 28 Jun 2016, Junio C Hamano wrote:
> And then that made me stare at the patch even more. We still write
> some error messages to stderr in the updated code (without my crap
> SQUASH) inside "while (!retval)" loop:
>
> while (retval == 0) {
> int band, len;
>
Junio C Hamano writes:
> With input from Dscho that recent Git-for-Windows does the right
> thing without limiting us to use only a subset of stdio, perhaps we
> would want to squash something like this in.
>
> diff --git a/sideband.c b/sideband.c
> index 226a8c2..72e2c5c 100644
> --- a/sideband.
Lukas Fleischer writes:
> Before this patch, we used character buffer manipulations to split
> messages from the sideband at line breaks and insert "remote: " at the
> beginning of each line, using the packet size to determine the end of a
> message. However, since it is safe to assume that diagn
Before this patch, we used character buffer manipulations to split
messages from the sideband at line breaks and insert "remote: " at the
beginning of each line, using the packet size to determine the end of a
message. However, since it is safe to assume that diagnostic messages
from the sideband n
21 matches
Mail list logo
