diff options
| author | Stefan Beller <sbeller@google.com> | 2016-07-15 00:49:46 +0300 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2016-07-15 01:50:40 +0300 |
| commit | c714e45f87301562b940e3621431ed7f7fbd16e5 (patch) | |
| tree | df0a4693d25514763b3f91dbaaa651c29f244627 /Documentation/technical | |
| parent | 77a9745d19b2b308c1ce97d18053322d1471bc4c (diff) | |
receive-pack: implement advertising and receiving push options
The pre/post receive hook may be interested in more information from the
user. This information can be transmitted when both client and server
support the "push-options" capability, which when used is a phase directly
after update commands ended by a flush pkt.
Similar to the atomic option, the server capability can be disabled via
the `receive.advertisePushOptions` config variable. While documenting
this, fix a nit in the `receive.advertiseAtomic` wording.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/technical')
| -rw-r--r-- | Documentation/technical/pack-protocol.txt | 10 | ||||
| -rw-r--r-- | Documentation/technical/protocol-capabilities.txt | 9 |
2 files changed, 15 insertions, 4 deletions
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 8b36343802..7a2ed30cfc 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -454,7 +454,8 @@ The reference discovery phase is done nearly the same way as it is in the fetching protocol. Each reference obj-id and name on the server is sent in packet-line format to the client, followed by a flush-pkt. The only real difference is that the capability listing is different - the only -possible values are 'report-status', 'delete-refs' and 'ofs-delta'. +possible values are 'report-status', 'delete-refs', 'ofs-delta' and +'push-options'. Reference Update Request and Packfile Transfer ---------------------------------------------- @@ -465,9 +466,10 @@ that it wants to update, it sends a line listing the obj-id currently on the server, the obj-id the client would like to update it to and the name of the reference. -This list is followed by a flush-pkt and then the packfile that should -contain all the objects that the server will need to complete the new -references. +This list is followed by a flush-pkt. Then the push options are transmitted +one per packet followed by another flush-pkt. After that the packfile that +should contain all the objects that the server will need to complete the new +references will be sent. ---- update-request = *shallow ( command-list | push-cert ) [packfile] diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index eaab6b4ac7..4c28d3a8ae 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -253,6 +253,15 @@ atomic pushes. If the pushing client requests this capability, the server will update the refs in one atomic transaction. Either all refs are updated or none. +push-options +------------ + +If the server sends the 'push-options' capability it is able to accept +push options after the update commands have been sent, but before the +packfile is streamed. If the pushing client requests this capability, +the server will pass the options to the pre- and post- receive hooks +that process this push request. + allow-tip-sha1-in-want ---------------------- |