Junio C Hamano writes:
> By clarifying that "sender SHOULD terminate with LF, receiver MUST
> NOT require it" is the rule (and fixing the existing implementations
> at places where they violate the "MUST NOT" part, which I think are
> very small number of places), I think we can drop these LF (or
On Mon, Jul 6, 2015 at 2:06 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano wrote:
>>> Dave Borowitz writes:
>>>
Another way of looking at the problem with my assumptions is, I was
assuming "pkt-line framing" was the same thing as
Dave Borowitz writes:
> On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano wrote:
>> Dave Borowitz writes:
>>
>>> Another way of looking at the problem with my assumptions is, I was
>>> assuming "pkt-line framing" was the same thing as "pkt-line header".
>>> You seem to be saying the definition of
Dave Borowitz writes:
>> That existing implementations of the receivers treat an empty packet
>> (i.e. "0004")
>
> or "0005\n" ;)
Is that true? I think
len = pkt_line();
if (!len)
break; /* flush */
would give you len == 1 and would not confuse it with a flush.
On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> Another way of looking at the problem with my assumptions is, I was
>> assuming "pkt-line framing" was the same thing as "pkt-line header".
>> You seem to be saying the definition of "pkt-line framing" is "header,
On Mon, Jul 6, 2015 at 1:30 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> I think I understand the confusion now. I think you and I are working
>> from different assumptions about the client behavior.
>
> I agree that we now both understand where we come from ;-)
>
> And sorry for not be
Dave Borowitz writes:
> Another way of looking at the problem with my assumptions is, I was
> assuming "pkt-line framing" was the same thing as "pkt-line header".
> You seem to be saying the definition of "pkt-line framing" is "header,
> and optional trailing newline".
Yes. I thought that was w
Dave Borowitz writes:
> I think I understand the confusion now. I think you and I are working
> from different assumptions about the client behavior.
I agree that we now both understand where we come from ;-)
And sorry for not being clear when I did the "push-cert" originally
in the documentati
On Mon, Jul 6, 2015 at 1:11 PM, Dave Borowitz wrote:
> On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano wrote:
>> Dave Borowitz writes:
>>
>>> The server can munge pkt-lines and reinsert LFs, but it _must_ have
>>> some way of reconstructing the payload that the client signed in order
>>> to veri
On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> The server can munge pkt-lines and reinsert LFs, but it _must_ have
>> some way of reconstructing the payload that the client signed in order
>> to verify the signature. If we just naively insert LFs where missing
Dave Borowitz writes:
> The server can munge pkt-lines and reinsert LFs, but it _must_ have
> some way of reconstructing the payload that the client signed in order
> to verify the signature. If we just naively insert LFs where missing,
> we lose the ability to verify the signature.
I still do n
On Mon, Jul 6, 2015 at 12:28 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> push cert format is like commit or tag format. You need those LFs. We
>> can't just go declare them optional because of the way pkt-line read
>> function is implemented in git-core.
>
> As I said, I view each of th
Shawn Pearce writes:
> push cert format is like commit or tag format. You need those LFs. We
> can't just go declare them optional because of the way pkt-line read
> function is implemented in git-core.
As I said, I view each of the packets between "push-cert" and
"push-cert-end" packets represe
Shawn Pearce writes:
> push cert format is like commit or tag format. You need those LFs. We
> can't just go declare them optional because of the way pkt-line read
> function is implemented in git-core.
As I said, I view each of the packets between "push-cert" and
"push-cert-end" packets represe
Dave Borowitz writes:
> Unfortunately, optional LFs still make the stored certs for later
> auditing and parsing a bit illegible. This is one way in which push
> certs are fundamentally different from the rest of the wire protocol,
> which is not intended to be persisted.
Hmm, I am not sure I fo
On Wed, Jul 1, 2015 at 1:49 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>>> I am moderately negative about this; wouldn't it make the end result
>>> cleaner to fix the implementation?
>>
>> I'm not sure I understand your suggestion. Are you saying, you would
>> prefer to make LFs optional
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz wrote:
> The alternatives for someone writing a parser are:
> a. Store the original pkt-line framing.
Or obviously, a2. Frame in some other way, e.g. JSON array of strings
(complete straw man, not seriously proposing this).
--
To unsubscribe from thi
On Mon, Jul 6, 2015 at 11:27 AM, Dave Borowitz wrote:
> On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz wrote:
>> b. Write a parser in some other clever way, e.g. parsing the entire
>> cert in reverse might work.
>
> ...as long as " " is illegal in nonce and pushee values, which it may
> be but is
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz wrote:
> b. Write a parser in some other clever way, e.g. parsing the entire
> cert in reverse might work.
...as long as " " is illegal in nonce and pushee values, which it may
be but is not explicitly documented. I still have no desire to write
such
On Mon, Jul 6, 2015 at 10:46 AM, Dave Borowitz wrote:
> On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano wrote:
>>
>> Dave Borowitz writes:
>>
>> >> I am moderately negative about this; wouldn't it make the end result
>> >> cleaner to fix the implementation?
>> >
>> > I'm not sure I understand you
On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano wrote:
>
> Dave Borowitz writes:
>
> >> I am moderately negative about this; wouldn't it make the end result
> >> cleaner to fix the implementation?
> >
> > I'm not sure I understand your suggestion. Are you saying, you would
> > prefer to make LFs o
On Fri, Jul 03, 2015 at 11:43:33AM -0700, Shawn Pearce wrote:
> > For (2), hopefully we can implement it in the same way, and rely on
> > empty sideband-0 packets. I haven't tested it in practice, though (I
> > have some very rough patches for (1) already).
>
> sideband-0 is not going to work for
On Fri, Jul 3, 2015 at 11:07 AM, Jeff King wrote:
> I wondered briefly whether this impacted the keepalives we added to
> `upload-pack` in 05e9515; those are implemented as 0-byte data packets,
> which we send during the potentially long counting/delta-compression
> phase before we send out pack d
On Fri, Jul 03, 2015 at 10:45:59AM -0700, Junio C Hamano wrote:
> > Usually flush packets are "", and an empty data packet
> > is "0004". Or are you talking about some kind of flush inside the
> > pkt-data stream?
>
> Neither. At the wire level there is a difference, but the callers
> of mos
Jeff King writes:
> On Wed, Jul 01, 2015 at 01:39:49PM -0700, Junio C Hamano wrote:
>
>> There is a slight complication on sending an empty line without any
>> termination, though ;-) The reader that calls packet_read() cannot
>> tell such a payload from a flush packet, I think.
>>
>> *That* ma
On Wed, Jul 01, 2015 at 01:39:49PM -0700, Junio C Hamano wrote:
> There is a slight complication on sending an empty line without any
> termination, though ;-) The reader that calls packet_read() cannot
> tell such a payload from a flush packet, I think.
>
> *That* may be something we want to do
Dave Borowitz writes:
>> I am moderately negative about this; wouldn't it make the end result
>> cleaner to fix the implementation?
>
> I'm not sure I understand your suggestion. Are you saying, you would
> prefer to make LFs optional in the push cert, for consistency with LFs
> being optional el
Junio C Hamano writes:
>> I am moderately negative about this; wouldn't it make the end result
>> cleaner to fix the implementation?
>
> I think that something like this should be sufficient. As the
> receiving end, we must not complain if there is no terminator.
> ...
And the change we are *no
Junio C Hamano writes:
> Dave Borowitz writes:
>
>> Signed-off-by: Dave Borowitz
>> ---
>> Documentation/technical/pack-protocol.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/technical/pack-protocol.txt
>> b/Documentation/technical/pack-protocol.txt
>> index
On Wed, Jul 1, 2015 at 1:00 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> Signed-off-by: Dave Borowitz
>> ---
>> Documentation/technical/pack-protocol.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/technical/pack-protocol.txt
>> b/Documentation/technic
Dave Borowitz writes:
> Signed-off-by: Dave Borowitz
> ---
> Documentation/technical/pack-protocol.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/technical/pack-protocol.txt
> b/Documentation/technical/pack-protocol.txt
> index 1386840..2d8b1a1 100644
> --- a/Docu
Signed-off-by: Dave Borowitz
---
Documentation/technical/pack-protocol.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index 1386840..2d8b1a1 100644
--- a/Documentation/technical/pack-protocol.txt
++
32 matches
Mail list logo
