| 1 | receive.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 | |
| 6 | receive.advertisePushOptions:: |
| 7 | When set to true, git-receive-pack will advertise the push options |
| 8 | capability to its clients. False by default. |
| 9 | |
| 10 | receive.autogc:: |
| 11 | By default, git-receive-pack will run "git maintenance run --auto" after |
| 12 | receiving data from git-push and updating refs. You can stop |
| 13 | it by setting this variable to false. |
| 14 | |
| 15 | receive.certNonceSeed:: |
| 16 | By setting this variable to a string, `git receive-pack` |
| 17 | will accept a `git push --signed` and verify it by using |
| 18 | a "nonce" protected by HMAC using this string as a secret |
| 19 | key. |
| 20 | |
| 21 | receive.certNonceSlop:: |
| 22 | When a `git push --signed` sends 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 | |
| 34 | receive.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 | |
| 40 | receive.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 | |
| 46 | receive.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 | |
| 52 | receive.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 | |
| 61 | receive.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 | |
| 71 | receive.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 | |
| 77 | receive.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 | |
| 81 | receive.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 | |
| 85 | receive.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 | + |
| 94 | Another option is "updateInstead" which will update the working |
| 95 | tree if pushing into the current branch. This option is |
| 96 | intended for synchronizing working directories when one side is not easily |
| 97 | accessible via interactive ssh (e.g. a live web site, hence the requirement |
| 98 | that the working directory be clean). This mode also comes in handy when |
| 99 | developing inside a VM to test and fix code on different Operating Systems. |
| 100 | + |
| 101 | By default, "updateInstead" will refuse the push if the working tree or |
| 102 | the index have any difference from the HEAD, but the `push-to-checkout` |
| 103 | hook can be used to customize this. See linkgit:githooks[5]. |
| 104 | |
| 105 | receive.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 | |
| 111 | receive.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 | |
| 117 | receive.procReceiveRefs:: |
| 118 | This is a multi-valued variable that defines reference prefixes |
| 119 | to match the commands in `receive-pack`. Commands matching the |
| 120 | prefixes will be executed by an external hook "proc-receive", |
| 121 | instead of the internal `execute_commands` function. If this |
| 122 | variable is not defined, the "proc-receive" hook will never be |
| 123 | used, and all commands will be executed by the internal |
| 124 | `execute_commands` function. |
| 125 | + |
| 126 | For example, if this variable is set to "refs/for", pushing to reference |
| 127 | such as "refs/for/master" will not create or update a reference named |
| 128 | "refs/for/master", but may create or update a pull request directly by |
| 129 | running the hook "proc-receive". |
| 130 | + |
| 131 | Optional modifiers can be provided in the beginning of the value to filter |
| 132 | commands for specific actions: create (a), modify (m), delete (d). |
| 133 | A `!` can be included in the modifiers to negate the reference prefix entry. |
| 134 | E.g.: |
| 135 | + |
| 136 | git config --system --add receive.procReceiveRefs ad:refs/heads |
| 137 | git config --system --add receive.procReceiveRefs !:refs/heads |
| 138 | |
| 139 | receive.updateServerInfo:: |
| 140 | If set to true, git-receive-pack will run git-update-server-info |
| 141 | after receiving data from git-push and updating refs. |
| 142 | |
| 143 | receive.shallowUpdate:: |
| 144 | If set to true, .git/shallow can be updated when new refs |
| 145 | require new shallow roots. Otherwise those refs are rejected. |