]>
Commit | Line | Data |
---|---|---|
aaa3b458 NTND |
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-gc --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 verifies 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` 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 | ||
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.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 | ||
121 | receive.shallowUpdate:: | |
122 | If set to true, .git/shallow can be updated when new refs | |
123 | require new shallow roots. Otherwise those refs are rejected. |