You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The `git-receive-pack` command immediately responds with one line for each reference it currently has – in this case, just the `master` branch and its SHA-1.
154
154
The first line also has a list of the server's capabilities (here, `report-status`, `delete-refs`, and some others, including the client identifier).
155
155
156
-
Each line starts with a 4-character hex value specifying how long the rest of the line is.
157
-
Your first line starts with 00a5, which is hexadecimal for 165, meaning that 165 bytes remain on that line.
158
-
The next line is 0000, meaning the server is done with its references listing.
156
+
The data is transmitted in chunks.
157
+
Each chunk starts with a 4-character hex value specifying how long the chunk is (including the 4 bytes of the length itself).
158
+
Chunks usually contain a single line of data and a trailing linefeed.
159
+
Your first chunk starts with 00a5, which is hexadecimal for 165, meaning the chunk is 165 bytes long.
160
+
The next chunk is 0000, meaning the server is done with its references listing.
159
161
160
162
Now that it knows the server's state, your `send-pack` process determines what commits it has that the server doesn't.
161
163
For each reference that this push will update, the `send-pack` process tells the `receive-pack` process that information.
@@ -209,6 +211,8 @@ The client then makes another request, this time a `POST`, with the data that `s
209
211
The `POST` request includes the `send-pack` output and the packfile as its payload.
210
212
The server then indicates success or failure with its HTTP response.
211
213
214
+
Keep in mind the HTTP protocol may further wrap this data inside a chunked transfer encoding.
0 commit comments