X-Git-Url: https://git.tokkee.org/?a=blobdiff_plain;f=Documentation%2Ftechnical%2Fpack-protocol.txt;h=369f91d3b949b23682c4deda8234f13513f15732;hb=55ac692661f7b850bb0160de18fa9868d24dbe17;hp=7950eeeda4447808c937b6ddcaa9ae1686e2ed5c;hpb=ad336054068074ed614d0bb54bb169e5263499d7;p=git.git

diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index 7950eeeda..369f91d3b 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -36,7 +36,7 @@ Git Transport
 
 The Git transport starts off by sending the command and repository
 on the wire using the pkt-line format, followed by a NUL byte and a
-hostname paramater, terminated by a NUL byte.
+hostname parameter, terminated by a NUL byte.
 
    0032git-upload-pack /project.git\0host=myserver.com\0
 
@@ -149,7 +149,7 @@ advertisement list at all, but other refs may still appear.
 The stream MUST include capability declarations behind a NUL on the
 first ref. The peeled value of a ref (that is "ref^{}") MUST be
 immediately after the ref itself, if presented. A conforming server
-MUST peel the ref if its an annotated tag.
+MUST peel the ref if it's an annotated tag.
 
 ----
   advertised-refs  =  (no-refs / list-of-refs)
@@ -261,7 +261,7 @@ Without either multi_ack or multi_ack_detailed:
 
  * upload-pack sends "NAK" on a flush-pkt if no common object
    has been found yet.  If one has been found, and thus an ACK
-   was already sent, its silent on the flush-pkt.
+   was already sent, it's silent on the flush-pkt.
 
 After the client has gotten enough ACK responses that it can determine
 that the server has enough information to send an efficient packfile
@@ -271,9 +271,9 @@ as common with the server, or the --date-order queue is empty), or the
 client determines that it wants to give up (in the canonical implementation,
 this is determined when the client sends 256 'have' lines without getting
 any of them ACKed by the server - meaning there is nothing in common and
-the server should just send all it's objects), then the client will send
+the server should just send all of its objects), then the client will send
 a 'done' command.  The 'done' command signals to the server that the client
-is ready to receive it's packfile data.
+is ready to receive its packfile data.
 
 However, the 256 limit *only* turns on in the canonical client
 implementation if we have received at least one "ACK %s continue"
@@ -286,7 +286,7 @@ ACK after 'done' if there is at least one common base and multi_ack or
 multi_ack_detailed is enabled. The server always sends NAK after 'done'
 if there is no common base found.
 
-Then the server will start sending it's packfile data.
+Then the server will start sending its packfile data.
 
 ----
   server-response = *ack_multi ack / nak
@@ -331,7 +331,7 @@ An incremental update (fetch) response might look like this:
 
    C: 0009done\n
 
-   S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d\n
+   S: 0031ACK 74730d410fcb6603ace96f1dc55ea6196122532d\n
    S: [PACKFILE]
 ----
 
@@ -488,7 +488,7 @@ An example client/server communication might look like this:
    C: 0000
    C: [PACKDATA]
 
-   S: 000aunpack ok\n
-   S: 0014ok refs/heads/debug\n
-   S: 0026ng refs/heads/master non-fast-forward\n
+   S: 000eunpack ok\n
+   S: 0018ok refs/heads/debug\n
+   S: 002ang refs/heads/master non-fast-forward\n
 ----