From: "Shawn O. Pearce" <spearce@spearce•org>
To: Scott Chacon <schacon@gmail•com>
Cc: Jakub Narebski <jnareb@gmail•com>,
git@vger•kernel.org, Junio C Hamano <gitster@pobox•com>,
Andreas Ericsson <ae@op5•se>, Tony Finch <dot@dotat•at>,
Johannes Sixt <j6t@kdbg•org>,
Linus Torvalds <torvalds@linux-foundation•org>
Subject: Re: Comments pack protocol description in "Git Community Book" (second round)
Date: Sun, 7 Jun 2009 13:43:43 -0700 [thread overview]
Message-ID: <20090607204343.GC16497@spearce.org> (raw)
In-Reply-To: <d411cc4a0906061458g494d80dbwe3a5358edfd1d49e@mail.gmail.com>
Scott Chacon <schacon@gmail•com> wrote:
> In addition to that, I started taking a shot at putting together an
> RFC formatted documentation of this protocol as was requested.
...
> http://git-scm.com/gitserver.txt
SSH is described by RFC 4251 and RFC 4254. Reference it when you
mention it.
Section 2.2.3 Commit is missing spaces after the parent, author,
committer, encoding headers:
> parent = "parent" + sha + \n
> userinfo = NAME <EMAIL> TIME
> author = "author" + userinfo + \n
> committer = "committer" + userinfo + \n
> encoding = "encoding" + encoding + \n
2.2.4. Tag, same problem.
> At the end of the
> packfile is a 20-byte SHA1 sum of all the shas in that packfile.
No. The SHA-1 checksum on the footer of the pack is over all of
the preceeding bytes of the pack.
> (B << 4) & A bytes when expanded
No. (B << 4) | A bytes when expanded.
> [1 byte] | 1 | type (3) | size A (4) | |- object #3 header
> +-------------------------------+ |
> [1 byte] | 0 | size data B (7) | |
> +-------------------------------+ |
> [1 byte] | 0 | size data C (7) | |
> +-------------------------------+ -+
> | compressed object data | (C << 11) & (B << 4) & A
> | | bytes when expanded
The B byte has the high bit set (1). And the length is
(C << 11) | (B << 4) | A.
Also, I found reading that difficult, and it doesn't mention the
OBJ_REF_DELTA or OBJ_OFS_DELTA cases.
You also need to note that the version number in the file header
is currently '2', as described by this RFC.
> Finally, the trailer records 20-byte SHA1 checksum of the rest of the
> file.
Like I said above, its the preceeding bytes of the pack.
Section 4.2 Git Protocol, explain the git:// URI first, and then
how a client splits that into the request, and then how it formats
the request. Don't forget to include an example with a non-standard
port number.
Also document what the standard port number is.
Elsewhere in the document you say 'upload-pack' or 'receive-pack'.
I think you should be saying 'git-upload-pack' or 'git-receive-pack'
everywhere, as these are the formal names in the protocol.
Section 5.2, Capabilities:
> Client sends space separated list of capabilities it wants. It
> SHOULD send a subset of server capabilities, i.e do not send
> capabilities served does not advertise. The client SHOULD NOT ask
> for capabilities the server did not say it supports.
I thought we had said it was client MUST send a subset of server
capabilities; client MUST NOT ask for capabilities server did
not advertise support of.
> Server MUST ignore capabilities it does not understand. Server MUST
> NOT ignore capabilities that client requested and server advertised.
I think that's just lazy coding on the server part. If the server
gets a capability request it can't honor, it MUST abort, it might
corrupt the stream to the client.
> 5.2.1. multi-ack
>
> The 'multi-ack' capability allows the server to return "ACK $SHA1
multi_ack
> Without multi_ack, a client sends have lines in --date-order until
> the server has found a common base. That means the client will send
Explain --date-order, don't assume the reader knows it.
I'm giving up for now. :-)
--
Shawn.
next prev parent reply other threads:[~2009-06-07 20:43 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
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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090607204343.GC16497@spearce.org \
--to=spearce@spearce$(echo .)org \
--cc=ae@op5$(echo .)se \
--cc=dot@dotat$(echo .)at \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=j6t@kdbg$(echo .)org \
--cc=jnareb@gmail$(echo .)com \
--cc=schacon@gmail$(echo .)com \
--cc=torvalds@linux-foundation$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox