Skip to content

Commit aaa3b45

Browse files
pcloudsgitster
authored andcommitted
config.txt: move receive part out to a separate file
Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 41b651d commit aaa3b45

File tree

2 files changed

+124
-123
lines changed

2 files changed

+124
-123
lines changed

Documentation/config.txt

Lines changed: 1 addition & 123 deletions
Original file line numberDiff line numberDiff line change
@@ -2564,129 +2564,7 @@ include::push-config.txt[]
25642564

25652565
include::rebase-config.txt[]
25662566

2567-
receive.advertiseAtomic::
2568-
By default, git-receive-pack will advertise the atomic push
2569-
capability to its clients. If you don't want to advertise this
2570-
capability, set this variable to false.
2571-
2572-
receive.advertisePushOptions::
2573-
When set to true, git-receive-pack will advertise the push options
2574-
capability to its clients. False by default.
2575-
2576-
receive.autogc::
2577-
By default, git-receive-pack will run "git-gc --auto" after
2578-
receiving data from git-push and updating refs. You can stop
2579-
it by setting this variable to false.
2580-
2581-
receive.certNonceSeed::
2582-
By setting this variable to a string, `git receive-pack`
2583-
will accept a `git push --signed` and verifies it by using
2584-
a "nonce" protected by HMAC using this string as a secret
2585-
key.
2586-
2587-
receive.certNonceSlop::
2588-
When a `git push --signed` sent a push certificate with a
2589-
"nonce" that was issued by a receive-pack serving the same
2590-
repository within this many seconds, export the "nonce"
2591-
found in the certificate to `GIT_PUSH_CERT_NONCE` to the
2592-
hooks (instead of what the receive-pack asked the sending
2593-
side to include). This may allow writing checks in
2594-
`pre-receive` and `post-receive` a bit easier. Instead of
2595-
checking `GIT_PUSH_CERT_NONCE_SLOP` environment variable
2596-
that records by how many seconds the nonce is stale to
2597-
decide if they want to accept the certificate, they only
2598-
can check `GIT_PUSH_CERT_NONCE_STATUS` is `OK`.
2599-
2600-
receive.fsckObjects::
2601-
If it is set to true, git-receive-pack will check all received
2602-
objects. See `transfer.fsckObjects` for what's checked.
2603-
Defaults to false. If not set, the value of
2604-
`transfer.fsckObjects` is used instead.
2605-
2606-
receive.fsck.<msg-id>::
2607-
Acts like `fsck.<msg-id>`, but is used by
2608-
linkgit:git-receive-pack[1] instead of
2609-
linkgit:git-fsck[1]. See the `fsck.<msg-id>` documentation for
2610-
details.
2611-
2612-
receive.fsck.skipList::
2613-
Acts like `fsck.skipList`, but is used by
2614-
linkgit:git-receive-pack[1] instead of
2615-
linkgit:git-fsck[1]. See the `fsck.skipList` documentation for
2616-
details.
2617-
2618-
receive.keepAlive::
2619-
After receiving the pack from the client, `receive-pack` may
2620-
produce no output (if `--quiet` was specified) while processing
2621-
the pack, causing some networks to drop the TCP connection.
2622-
With this option set, if `receive-pack` does not transmit
2623-
any data in this phase for `receive.keepAlive` seconds, it will
2624-
send a short keepalive packet. The default is 5 seconds; set
2625-
to 0 to disable keepalives entirely.
2626-
2627-
receive.unpackLimit::
2628-
If the number of objects received in a push is below this
2629-
limit then the objects will be unpacked into loose object
2630-
files. However if the number of received objects equals or
2631-
exceeds this limit then the received pack will be stored as
2632-
a pack, after adding any missing delta bases. Storing the
2633-
pack from a push can make the push operation complete faster,
2634-
especially on slow filesystems. If not set, the value of
2635-
`transfer.unpackLimit` is used instead.
2636-
2637-
receive.maxInputSize::
2638-
If the size of the incoming pack stream is larger than this
2639-
limit, then git-receive-pack will error out, instead of
2640-
accepting the pack file. If not set or set to 0, then the size
2641-
is unlimited.
2642-
2643-
receive.denyDeletes::
2644-
If set to true, git-receive-pack will deny a ref update that deletes
2645-
the ref. Use this to prevent such a ref deletion via a push.
2646-
2647-
receive.denyDeleteCurrent::
2648-
If set to true, git-receive-pack will deny a ref update that
2649-
deletes the currently checked out branch of a non-bare repository.
2650-
2651-
receive.denyCurrentBranch::
2652-
If set to true or "refuse", git-receive-pack will deny a ref update
2653-
to the currently checked out branch of a non-bare repository.
2654-
Such a push is potentially dangerous because it brings the HEAD
2655-
out of sync with the index and working tree. If set to "warn",
2656-
print a warning of such a push to stderr, but allow the push to
2657-
proceed. If set to false or "ignore", allow such pushes with no
2658-
message. Defaults to "refuse".
2659-
+
2660-
Another option is "updateInstead" which will update the working
2661-
tree if pushing into the current branch. This option is
2662-
intended for synchronizing working directories when one side is not easily
2663-
accessible via interactive ssh (e.g. a live web site, hence the requirement
2664-
that the working directory be clean). This mode also comes in handy when
2665-
developing inside a VM to test and fix code on different Operating Systems.
2666-
+
2667-
By default, "updateInstead" will refuse the push if the working tree or
2668-
the index have any difference from the HEAD, but the `push-to-checkout`
2669-
hook can be used to customize this. See linkgit:githooks[5].
2670-
2671-
receive.denyNonFastForwards::
2672-
If set to true, git-receive-pack will deny a ref update which is
2673-
not a fast-forward. Use this to prevent such an update via a push,
2674-
even if that push is forced. This configuration variable is
2675-
set when initializing a shared repository.
2676-
2677-
receive.hideRefs::
2678-
This variable is the same as `transfer.hideRefs`, but applies
2679-
only to `receive-pack` (and so affects pushes, but not fetches).
2680-
An attempt to update or delete a hidden ref by `git push` is
2681-
rejected.
2682-
2683-
receive.updateServerInfo::
2684-
If set to true, git-receive-pack will run git-update-server-info
2685-
after receiving data from git-push and updating refs.
2686-
2687-
receive.shallowUpdate::
2688-
If set to true, .git/shallow can be updated when new refs
2689-
require new shallow roots. Otherwise those refs are rejected.
2567+
include::receive-config.txt[]
26902568

26912569
remote.pushDefault::
26922570
The remote to push to by default. Overrides

Documentation/receive-config.txt

Lines changed: 123 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,123 @@
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.

0 commit comments

Comments
 (0)