git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Scott Chacon <schacon@gmail.com>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: Request for detailed documentation of git pack protocol
Date: Thu, 4 Jun 2009 00:04:09 +0200	[thread overview]
Message-ID: <200906040004.18594.jnareb@gmail.com> (raw)
In-Reply-To: <20090603202429.GO3355@spearce.org>

On Wed, 3 Jun 2009, Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:

> > BTW. do "include-tag" capability MUST NOT (REQUIRED) be send if there
> > are not tags (tag objects?), or just SHOULD NOT (RECOMMENDED), or even
> > MAY NOT (OPTIONAL).  GitHub server doesn't send it if there are no 
> > tags...
> 
> Clients MAY always send include-tag, hardcoding it into a request.
> The decision for a client to request include-tag only has to do
> with the client's desires for tag data, whether or not a server
> had advertised objects in the refs/tags/* namespace.
> 
> Clients SHOULD NOT send include-tag if remote.name.tagopt was set
> to --no-tags, as the client doesn't want tag data.
> 
> Servers MUST accept include-tag without error or warning, even if the
> server does not understand or support the option.
> 
> Servers SHOULD pack the tags if their referrant is packed and the
> client has requested include-tag.
> 
> Clients MUST be prepared for the case where a server has ignored
> include-tag and has not actually sent tags in the pack.  In such
> cases the client SHOULD issue a subsequent fetch to acquire the
> tags that include-tag would have otherwise given the client.

So do I understand correctly that capabilities are governed by the
following generic rules:

1. Server sends space separated list of capabilities it support. It
   MUST NOT send capabilities it *does not* support. It MAY NOT send
   "include-tag" if there are no tag objects (or is it SHOULD NOT?).
2. Client sends space separated list of capabilities it wants. It SHOULD
   (or perhaps it is MAY?) send subset of server capabilities, i.e do
   not send capabilities served does not advertise.
3. Server MUST ignore capabilities it does not understand. Server MUST
   NOT ignore capabilities (or SHOULD NOT only?) that client requested
   and server advertised.

I know that client MUST send only maximum of one of "side-band" and 
"side-band-64k", but how should server reacts if client sends both?
Should it use "side-band-64k"?

-- 
Jakub Narebski
Poland

  reply	other threads:[~2009-06-03 21:59 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-12 21:29 Request for detailed documentation of git pack protocol Jakub Narebski
2009-05-12 23:34 ` Shawn O. Pearce
2009-05-14  8:24   ` Jakub Narebski
2009-05-14 14:57     ` Shawn O. Pearce
2009-05-14 15:02       ` Andreas Ericsson
2009-05-15 20:29         ` Linus Torvalds
2009-05-15 16:51       ` Clemens Buchacher
2009-05-14 18:13     ` Nicolas Pitre
2009-05-14 20:27       ` Jakub Narebski
2009-05-14 13:55   ` Scott Chacon
2009-05-14 14:44     ` Shawn O. Pearce
2009-05-14 15:01     ` Jakub Narebski
2009-05-15  0:58       ` A Large Angry SCM
2009-05-15 19:05         ` Ealdwulf Wuffinga
2009-06-02 21:39     ` Jakub Narebski
2009-06-02 23:27       ` Shawn O. Pearce
2009-06-03  0:50         ` Jakub Narebski
2009-06-03  1:29           ` Shawn O. Pearce
2009-06-03  2:11             ` Junio C Hamano
2009-06-03  2:15               ` Shawn O. Pearce
2009-06-03  9:21             ` Jakub Narebski
2009-06-03 14:48               ` Shawn O. Pearce
2009-06-03 15:07                 ` Shawn O. Pearce
2009-06-03 15:39                   ` Jakub Narebski
2009-06-03 15:50                     ` Shawn O. Pearce
2009-06-03 16:51                 ` Jakub Narebski
2009-06-03 16:56                   ` Shawn O. Pearce
2009-06-03 20:19                     ` Jakub Narebski
2009-06-03 20:24                       ` Shawn O. Pearce
2009-06-03 22:04                         ` Jakub Narebski [this message]
2009-06-03 22:04                           ` Shawn O. Pearce
2009-06-03 22:16                           ` Junio C Hamano
2009-06-03 22:46                             ` Jakub Narebski
2009-06-04  7:17                         ` Andreas Ericsson
2009-06-04  7:26                           ` Junio C Hamano
2009-06-06 16:33                     ` Scott Chacon
2009-06-06 17:24                       ` Junio C Hamano
2009-06-06 17:41                       ` Jakub Narebski
2009-06-03 21:38                   ` Tony Finch
2009-06-03 17:11                 ` Junio C Hamano
2009-06-03 19:05                 ` Johannes Sixt
2009-06-03  2:18           ` Robin H. Johnson
2009-06-03 10:47             ` Jakub Narebski
2009-06-03 14:17               ` Shawn O. Pearce
2009-06-03 20:56           ` Tony Finch
2009-06-03 21:20             ` Jakub Narebski
2009-06-03 21:53               ` Tony Finch
2009-06-04  8:45                 ` Jakub Narebski
2009-06-04 11:41                   ` Tony Finch
2009-06-04 18:41                   ` Shawn O. Pearce
2009-06-03 12:29       ` Jakub Narebski
2009-06-03 14:19         ` Shawn O. Pearce
2009-06-04 20:55       ` Jakub Narebski
2009-06-04 21:57         ` Shawn O. Pearce
2009-06-05  0:45         ` Shawn O. Pearce
2009-06-05  7:24           ` Jakub Narebski
2009-06-05  8:45             ` Jakub Narebski
2009-06-06 21:38       ` Comments pack protocol description in "Git Community Book" (second round) Jakub Narebski
2009-06-06 21:58         ` Scott Chacon
2009-06-07  8:21           ` Jakub Narebski
2009-06-07 20:13             ` Shawn O. Pearce
2009-06-07 20:43           ` Shawn O. Pearce
2009-06-13  9:30           ` Comments pack protocol description in "RFC for the Git Packfile Protocol" (long) Jakub Narebski
2009-06-07 20:06         ` Comments pack protocol description in "Git Community Book" (second round) Shawn O. Pearce
2009-06-09  9:39           ` Jakub Narebski
2009-06-09 14:28             ` Shawn O. Pearce

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=200906040004.18594.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=schacon@gmail.com \
    --cc=spearce@spearce.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).