config.txt: move push 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
41b651d669ed3200e89220be35d93af3817a187f
2 files changed
+114
-113
Documentation/config.txt
+1
-113
@@ -2560,119 +2560,7 @@ protocol.version::
2560
2561
include::pull-config.txt[]
2562
2563
-push.default::
2564
- Defines the action `git push` should take if no refspec is
2565
- explicitly given. Different values are well-suited for
2566
- specific workflows; for instance, in a purely central workflow
2567
- (i.e. the fetch source is equal to the push destination),
2568
- `upstream` is probably what you want. Possible values are:
2569
-+
2570
---
2571
-
2572
-* `nothing` - do not push anything (error out) unless a refspec is
2573
- explicitly given. This is primarily meant for people who want to
2574
- avoid mistakes by always being explicit.
2575
-
2576
-* `current` - push the current branch to update a branch with the same
2577
- name on the receiving end. Works in both central and non-central
2578
- workflows.
2579
-
2580
-* `upstream` - push the current branch back to the branch whose
2581
- changes are usually integrated into the current branch (which is
2582
- called `@{upstream}`). This mode only makes sense if you are
2583
- pushing to the same repository you would normally pull from
2584
- (i.e. central workflow).
2585
-
2586
-* `tracking` - This is a deprecated synonym for `upstream`.
2587
-
2588
-* `simple` - in centralized workflow, work like `upstream` with an
2589
- added safety to refuse to push if the upstream branch's name is
2590
- different from the local one.
2591
-+
2592
-When pushing to a remote that is different from the remote you normally
2593
-pull from, work as `current`. This is the safest option and is suited
2594
-for beginners.
2595
-+
2596
-This mode has become the default in Git 2.0.
2597
-
2598
-* `matching` - push all branches having the same name on both ends.
2599
- This makes the repository you are pushing to remember the set of
2600
- branches that will be pushed out (e.g. if you always push 'maint'
2601
- and 'master' there and no other branches, the repository you push
2602
- to will have these two branches, and your local 'maint' and
2603
- 'master' will be pushed there).
2604
-+
2605
-To use this mode effectively, you have to make sure _all_ the
2606
-branches you would push out are ready to be pushed out before
2607
-running 'git push', as the whole point of this mode is to allow you
2608
-to push all of the branches in one go. If you usually finish work
2609
-on only one branch and push out the result, while other branches are
2610
-unfinished, this mode is not for you. Also this mode is not
2611
-suitable for pushing into a shared central repository, as other
2612
-people may add new branches there, or update the tip of existing
2613
-branches outside your control.
2614
-+
2615
-This used to be the default, but not since Git 2.0 (`simple` is the
2616
-new default).
2617
-
2618
---
2619
-
2620
-push.followTags::
2621
- If set to true enable `--follow-tags` option by default. You
2622
- may override this configuration at time of push by specifying
2623
- `--no-follow-tags`.
2624
-
2625
-push.gpgSign::
2626
- May be set to a boolean value, or the string 'if-asked'. A true
2627
- value causes all pushes to be GPG signed, as if `--signed` is
2628
- passed to linkgit:git-push[1]. The string 'if-asked' causes
2629
- pushes to be signed if the server supports it, as if
2630
- `--signed=if-asked` is passed to 'git push'. A false value may
2631
- override a value from a lower-priority config file. An explicit
2632
- command-line flag always overrides this config option.
2633
-
2634
-push.pushOption::
2635
- When no `--push-option=<option>` argument is given from the
2636
- command line, `git push` behaves as if each <value> of
2637
- this variable is given as `--push-option=<value>`.
2638
-+
2639
-This is a multi-valued variable, and an empty value can be used in a
2640
-higher priority configuration file (e.g. `.git/config` in a
2641
-repository) to clear the values inherited from a lower priority
2642
-configuration files (e.g. `$HOME/.gitconfig`).
2643
-+
2644
---
2645
-
2646
-Example:
2647
-
2648
-/etc/gitconfig
2649
- push.pushoption = a
2650
- push.pushoption = b
2651
-
2652
-~/.gitconfig
2653
- push.pushoption = c
2654
-
2655
-repo/.git/config
2656
- push.pushoption =
2657
- push.pushoption = b
2658
-
2659
-This will result in only b (a and c are cleared).
2660
-
2661
---
2662
-
2663
-push.recurseSubmodules::
2664
- Make sure all submodule commits used by the revisions to be pushed
2665
- are available on a remote-tracking branch. If the value is 'check'
2666
- then Git will verify that all submodule commits that changed in the
2667
- revisions to be pushed are available on at least one remote of the
2668
- submodule. If any commits are missing, the push will be aborted and
2669
- exit with non-zero status. If the value is 'on-demand' then all
2670
- submodules that changed in the revisions to be pushed will be
2671
- pushed. If on-demand was not able to push all necessary revisions
2672
- it will also be aborted and exit with non-zero status. If the value
2673
- is 'no' then default behavior of ignoring submodules when pushing
2674
- is retained. You may override this configuration at time of push by
2675
- specifying '--recurse-submodules=check|on-demand|no'.
2563
+include::push-config.txt[]
2564
2565
include::rebase-config.txt[]
2566
Documentation/push-config.txt
new
+113
@@ -0,0 +1,113 @@
1
+push.default::
2
+ Defines the action `git push` should take if no refspec is
3
+ explicitly given. Different values are well-suited for
4
+ specific workflows; for instance, in a purely central workflow
5
+ (i.e. the fetch source is equal to the push destination),
6
+ `upstream` is probably what you want. Possible values are:
7
++
8
+--
9
+
10
+* `nothing` - do not push anything (error out) unless a refspec is
11
+ explicitly given. This is primarily meant for people who want to
12
+ avoid mistakes by always being explicit.
13
+
14
+* `current` - push the current branch to update a branch with the same
15
+ name on the receiving end. Works in both central and non-central
16
+ workflows.
17
+
18
+* `upstream` - push the current branch back to the branch whose
19
+ changes are usually integrated into the current branch (which is
20
+ called `@{upstream}`). This mode only makes sense if you are
21
+ pushing to the same repository you would normally pull from
22
+ (i.e. central workflow).
23
+
24
+* `tracking` - This is a deprecated synonym for `upstream`.
25
+
26
+* `simple` - in centralized workflow, work like `upstream` with an
27
+ added safety to refuse to push if the upstream branch's name is
28
+ different from the local one.
29
++
30
+When pushing to a remote that is different from the remote you normally
31
+pull from, work as `current`. This is the safest option and is suited
32
+for beginners.
33
++
34
+This mode has become the default in Git 2.0.
35
+
36
+* `matching` - push all branches having the same name on both ends.
37
+ This makes the repository you are pushing to remember the set of
38
+ branches that will be pushed out (e.g. if you always push 'maint'
39
+ and 'master' there and no other branches, the repository you push
40
+ to will have these two branches, and your local 'maint' and
41
+ 'master' will be pushed there).
42
++
43
+To use this mode effectively, you have to make sure _all_ the
44
+branches you would push out are ready to be pushed out before
45
+running 'git push', as the whole point of this mode is to allow you
46
+to push all of the branches in one go. If you usually finish work
47
+on only one branch and push out the result, while other branches are
48
+unfinished, this mode is not for you. Also this mode is not
49
+suitable for pushing into a shared central repository, as other
50
+people may add new branches there, or update the tip of existing
51
+branches outside your control.
52
++
53
+This used to be the default, but not since Git 2.0 (`simple` is the
54
+new default).
55
+
56
+--
57
+
58
+push.followTags::
59
+ If set to true enable `--follow-tags` option by default. You
60
+ may override this configuration at time of push by specifying
61
+ `--no-follow-tags`.
62
+
63
+push.gpgSign::
64
+ May be set to a boolean value, or the string 'if-asked'. A true
65
+ value causes all pushes to be GPG signed, as if `--signed` is
66
+ passed to linkgit:git-push[1]. The string 'if-asked' causes
67
+ pushes to be signed if the server supports it, as if
68
+ `--signed=if-asked` is passed to 'git push'. A false value may
69
+ override a value from a lower-priority config file. An explicit
70
+ command-line flag always overrides this config option.
71
+
72
+push.pushOption::
73
+ When no `--push-option=<option>` argument is given from the
74
+ command line, `git push` behaves as if each <value> of
75
+ this variable is given as `--push-option=<value>`.
76
++
77
+This is a multi-valued variable, and an empty value can be used in a
78
+higher priority configuration file (e.g. `.git/config` in a
79
+repository) to clear the values inherited from a lower priority
80
+configuration files (e.g. `$HOME/.gitconfig`).
81
++
82
+--
83
+
84
+Example:
85
+
86
+/etc/gitconfig
87
+ push.pushoption = a
88
+ push.pushoption = b
89
+
90
+~/.gitconfig
91
+ push.pushoption = c
92
+
93
+repo/.git/config
94
+ push.pushoption =
95
+ push.pushoption = b
96
+
97
+This will result in only b (a and c are cleared).
98
+
99
+--
100
+
101
+push.recurseSubmodules::
102
+ Make sure all submodule commits used by the revisions to be pushed
103
+ are available on a remote-tracking branch. If the value is 'check'
104
+ then Git will verify that all submodule commits that changed in the
105
+ revisions to be pushed are available on at least one remote of the
106
+ submodule. If any commits are missing, the push will be aborted and
107
+ exit with non-zero status. If the value is 'on-demand' then all
108
+ submodules that changed in the revisions to be pushed will be
109
+ pushed. If on-demand was not able to push all necessary revisions
110
+ it will also be aborted and exit with non-zero status. If the value
111
+ is 'no' then default behavior of ignoring submodules when pushing
112
+ is retained. You may override this configuration at time of push by
113
+ specifying '--recurse-submodules=check|on-demand|no'.