config.txt: move receive part out to a separate file
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nguyễn Thái Ngọc Duy committed
Aug 22, 2018 at 18:06 UTC
aaa3b458eee6665d7bcd70432c9cba3acc6334c0
2 files changed
+124
-123
Documentation/config.txt
+1
-123
@@ -2564,129 +2564,7 @@ include::push-config.txt[]
2564
2565
include::rebase-config.txt[]
2566
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[]
2568
2569
remote.pushDefault::
2570
The remote to push to by default. Overrides
Documentation/receive-config.txt
new
+123
@@ -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.