path: root/Documentation/technical
diff options
Diffstat (limited to 'Documentation/technical')
3 files changed, 8 insertions, 8 deletions
diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt
index b26c281..68bf4ca 100644
--- a/Documentation/technical/api-run-command.txt
+++ b/Documentation/technical/api-run-command.txt
@@ -51,7 +51,7 @@ The functions above do the following:
ENOENT; a diagnostic is printed only if .silent_exec_failure is 0.
. Otherwise, the program is run. If it terminates regularly, its exit
- code is returned. No diagnistic is printed, even if the exit code is
+ code is returned. No diagnostic is printed, even if the exit code is
. If the program terminated due to a signal, then the return value is the
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index 7950eee..9a5cdaf 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -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
diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt
index 1892d3e..fd1a593 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -60,7 +60,7 @@ doesn't, as in the following diagram:
If the client wants x,y and starts out by saying have F,S, the server
doesn't know what F,S is. Eventually the client says "have d" and
the server sends "ACK d continue" to let the client know to stop
-walking down that line (so don't send c-b-a), but its not done yet,
+walking down that line (so don't send c-b-a), but it's not done yet,
it needs a base for x. The client keeps going with S-R-Q, until a
gets reached, at which point the server has a clear base and it all
@@ -181,7 +181,7 @@ delete-refs
If the server sends back the 'delete-refs' capability, it means that
-it is capable of accepting an zero-id value as the target
+it is capable of accepting a zero-id value as the target
value of a reference update. It is not sent back by the client, it
simply informs the client that it can be sent zero-id values
to delete references.