All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Scott Chacon <schacon@gmail.com>, git list <git@vger.kernel.org>
Subject: Re: [PATCH] Update packfile transfer protocol documentation
Date: Tue, 3 Nov 2009 17:18:03 -0800	[thread overview]
Message-ID: <20091104011802.GE10505@spearce.org> (raw)
In-Reply-To: <7vljinnllj.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > I don't think we ever send an empty packet.  If we have no data to
> > send, why the hell did we create the packet header?
> 
> Oh, I do not disagree that it is pointless, but the example that followed
> the part we are discussing also had "0004".  I think it is Ok to allow it.

If its pointless, why encourage it?  Why not discourage it with SHOULD NOT?
 
> The original intent of packet_flush() was that everything else could be
> kept buffered in-core without going to write() until packet_flush() is
> called.  The protocol was defined in a way that we won't wait for
> listening a response from the other end to an earlier message we "sent"
> with packet_write() but haven't called packet_flush() yet hence could
> still be in our buffer.  We still have this comment:
> 
>     /*
>      * If we buffered things up above (we don't, but we should),
>      * we'd flush it here
>      */
>     void packet_flush(int fd)

The smart-http series causes fetch-pack to buffer.  :-)

> And once we start buffering, allowing "0004" packet_write() wouldn't even
> be a problem; it can be optimized out in the buffering layer.

Sure, but can't packet_write just return early without write()
if format_packet returned 4 (aka vsnprintf returned 0)?

-- 
Shawn.

  reply	other threads:[~2009-11-04  1:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-01 23:18 [PATCH] Update packfile transfer protocol documentation Scott Chacon
2009-11-02  5:17 ` Junio C Hamano
2009-11-02 15:41   ` Shawn O. Pearce
2009-11-02 17:31     ` Junio C Hamano
2009-11-02 15:43 ` Shawn O. Pearce
2009-11-02 23:48 ` Junio C Hamano
2009-11-02 23:57   ` Shawn O. Pearce
2009-11-03  0:36     ` Junio C Hamano
2009-11-03  0:58       ` Shawn O. Pearce
2009-11-03 22:05         ` Scott Chacon
2009-11-04  0:40           ` Junio C Hamano
2009-11-04  0:40 ` Junio C Hamano
2009-11-04  0:56   ` Shawn O. Pearce
2009-11-04  1:07     ` Junio C Hamano
2009-11-04  1:18       ` Shawn O. Pearce [this message]
2009-11-04  1:48         ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2009-11-04  5:58 Scott Chacon
2009-11-04  6:36 ` Sverre Rabbelier
2009-11-05  5:24 ` Junio C Hamano
2009-10-29 17:35 Scott Chacon
2009-10-30 22:07 ` Junio C Hamano
2009-10-31  2:06 ` Shawn O. Pearce
2009-10-31 20:12   ` Johannes Sixt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091104011802.GE10505@spearce.org \
    --to=spearce@spearce.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=schacon@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.