aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/gitprotocol-capabilities.txt
diff options
context:
space:
mode:
authorElijah Newren <newren@gmail.com>2023-10-08 06:45:03 +0000
committerJunio C Hamano <gitster@pobox.com>2023-10-09 12:04:21 -0700
commitcf6cac20059123d6ec3f867bb3692df62db52cf9 (patch)
tree99e0ee363183782b239257d69d28282c44100136 /Documentation/gitprotocol-capabilities.txt
parent3a06386e314565108ad56a9bdb8f7b80ac52fb69 (diff)
downloadgit-cf6cac20059123d6ec3f867bb3692df62db52cf9.tar.gz
documentation: wording improvements
Diff best viewed with --color-diff. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/gitprotocol-capabilities.txt')
-rw-r--r--Documentation/gitprotocol-capabilities.txt14
1 files changed, 7 insertions, 7 deletions
diff --git a/Documentation/gitprotocol-capabilities.txt b/Documentation/gitprotocol-capabilities.txt
index 0fb5ea0c1c..5d5e39a703 100644
--- a/Documentation/gitprotocol-capabilities.txt
+++ b/Documentation/gitprotocol-capabilities.txt
@@ -61,8 +61,8 @@ complete cut across the DAG, or the client has said "done".
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
have lines that are already known by the server to be common, because
-they overlap in time with another branch that the server hasn't found
-a common base on yet.
+they overlap in time with another branch on which the server hasn't found
+a common base yet.
For example suppose the client has commits in caps that the server
doesn't and the server has commits in lower case that the client
@@ -135,7 +135,7 @@ to disable the feature in a backwards-compatible manner.
side-band, side-band-64k
------------------------
-This capability means that server can send, and client understand multiplexed
+This capability means that the server can send, and the client can understand, multiplexed
progress reports and error info interleaved with the packfile itself.
These two options are mutually exclusive. A modern client always
@@ -163,14 +163,14 @@ Further, with side-band and its up to 1000-byte messages, it's actually
same deal, you have up to 65519 bytes of data and 1 byte for the stream
code.
-The client MUST send only maximum of one of "side-band" and "side-
-band-64k". Server MUST diagnose it as an error if client requests
+The client MUST send only one of "side-band" and "side-
+band-64k". The server MUST diagnose it as an error if client requests
both.
ofs-delta
---------
-Server can send, and client understand PACKv2 with delta referring to
+The server can send, and the client can understand, PACKv2 with delta referring to
its base by position in pack rather than by an obj-id. That is, they can
send/read OBJ_OFS_DELTA (aka type 6) in a packfile.
@@ -252,7 +252,7 @@ the current shallow boundary, instead of the depth from remote refs.
no-progress
-----------
-The client was started with "git clone -q" or something, and doesn't
+The client was started with "git clone -q" or something similar, and doesn't
want that side band 2. Basically the client just says "I do not
wish to receive stream 2 on sideband, so do not send it to me, and if
you did, I will drop it on the floor anyway". However, the sideband