1receive.advertiseAtomic:: 2 By default, git-receive-pack will advertise the atomic push 3 capability to its clients. If you don't want to advertise this 4 capability, set this variable to false. 5 6receive.advertisePushOptions:: 7 When set to true, git-receive-pack will advertise the push options 8 capability to its clients. False by default. 9 10receive.autogc:: 11 By default, git-receive-pack will run "git-gc --auto" after 12 receiving data from git-push and updating refs. You can stop 13 it by setting this variable to false. 14 15receive.certNonceSeed:: 16 By setting this variable to a string, `git receive-pack` 17 will accept a `git push --signed` and verifies it by using 18 a "nonce" protected by HMAC using this string as a secret 19 key. 20 21receive.certNonceSlop:: 22 When a `git push --signed` sent a push certificate with a 23 "nonce" that was issued by a receive-pack serving the same 24 repository within this many seconds, export the "nonce" 25 found in the certificate to `GIT_PUSH_CERT_NONCE` to the 26 hooks (instead of what the receive-pack asked the sending 27 side to include). This may allow writing checks in 28 `pre-receive` and `post-receive` a bit easier. Instead of 29 checking `GIT_PUSH_CERT_NONCE_SLOP` environment variable 30 that records by how many seconds the nonce is stale to 31 decide if they want to accept the certificate, they only 32 can check `GIT_PUSH_CERT_NONCE_STATUS` is `OK`. 33 34receive.fsckObjects:: 35 If it is set to true, git-receive-pack will check all received 36 objects. See `transfer.fsckObjects` for what's checked. 37 Defaults to false. If not set, the value of 38 `transfer.fsckObjects` is used instead. 39 40receive.fsck.<msg-id>:: 41 Acts like `fsck.<msg-id>`, but is used by 42 linkgit:git-receive-pack[1] instead of 43 linkgit:git-fsck[1]. See the `fsck.<msg-id>` documentation for 44 details. 45 46receive.fsck.skipList:: 47 Acts like `fsck.skipList`, but is used by 48 linkgit:git-receive-pack[1] instead of 49 linkgit:git-fsck[1]. See the `fsck.skipList` documentation for 50 details. 51 52receive.keepAlive:: 53 After receiving the pack from the client, `receive-pack` may 54 produce no output (if `--quiet` was specified) while processing 55 the pack, causing some networks to drop the TCP connection. 56 With this option set, if `receive-pack` does not transmit 57 any data in this phase for `receive.keepAlive` seconds, it will 58 send a short keepalive packet. The default is 5 seconds; set 59 to 0 to disable keepalives entirely. 60 61receive.unpackLimit:: 62 If the number of objects received in a push is below this 63 limit then the objects will be unpacked into loose object 64 files. However if the number of received objects equals or 65 exceeds this limit then the received pack will be stored as 66 a pack, after adding any missing delta bases. Storing the 67 pack from a push can make the push operation complete faster, 68 especially on slow filesystems. If not set, the value of 69 `transfer.unpackLimit` is used instead. 70 71receive.maxInputSize:: 72 If the size of the incoming pack stream is larger than this 73 limit, then git-receive-pack will error out, instead of 74 accepting the pack file. If not set or set to 0, then the size 75 is unlimited. 76 77receive.denyDeletes:: 78 If set to true, git-receive-pack will deny a ref update that deletes 79 the ref. Use this to prevent such a ref deletion via a push. 80 81receive.denyDeleteCurrent:: 82 If set to true, git-receive-pack will deny a ref update that 83 deletes the currently checked out branch of a non-bare repository. 84 85receive.denyCurrentBranch:: 86 If set to true or "refuse", git-receive-pack will deny a ref update 87 to the currently checked out branch of a non-bare repository. 88 Such a push is potentially dangerous because it brings the HEAD 89 out of sync with the index and working tree. If set to "warn", 90 print a warning of such a push to stderr, but allow the push to 91 proceed. If set to false or "ignore", allow such pushes with no 92 message. Defaults to "refuse". 93+ 94Another option is "updateInstead" which will update the working 95tree if pushing into the current branch. This option is 96intended for synchronizing working directories when one side is not easily 97accessible via interactive ssh (e.g. a live web site, hence the requirement 98that the working directory be clean). This mode also comes in handy when 99developing inside a VM to test and fix code on different Operating Systems. 100+ 101By default, "updateInstead" will refuse the push if the working tree or 102the index have any difference from the HEAD, but the `push-to-checkout` 103hook can be used to customize this. See linkgit:githooks[5]. 104 105receive.denyNonFastForwards:: 106 If set to true, git-receive-pack will deny a ref update which is 107 not a fast-forward. Use this to prevent such an update via a push, 108 even if that push is forced. This configuration variable is 109 set when initializing a shared repository. 110 111receive.hideRefs:: 112 This variable is the same as `transfer.hideRefs`, but applies 113 only to `receive-pack` (and so affects pushes, but not fetches). 114 An attempt to update or delete a hidden ref by `git push` is 115 rejected. 116 117receive.updateServerInfo:: 118 If set to true, git-receive-pack will run git-update-server-info 119 after receiving data from git-push and updating refs. 120 121receive.shallowUpdate:: 122 If set to true, .git/shallow can be updated when new refs 123 require new shallow roots. Otherwise those refs are rejected.