3b5bf96573
Update test cases for the new option, and document its usage
and update related references.
Update test cases for the new option, and document its usage
and update related references.
- t/t5533-push-cas.sh:
Update test cases for "compare-and-swap" when used along with
"--force-if-includes" helps mitigate overwrites when remote
refs are updated in the background; allows forced updates when
changes from remote are integrated locally.
- Documentation:
Add reference for the new option, configuration setting
("push.useForceIfIncludes") and advise messages.
Signed-off-by: Srinidhi Kaushik <shrinidhi.kaushik@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
123 lines
4.8 KiB
Plaintext
123 lines
4.8 KiB
Plaintext
push.default::
|
|
Defines the action `git push` should take if no refspec is
|
|
given (whether from the command-line, config, or elsewhere).
|
|
Different values are well-suited for
|
|
specific workflows; for instance, in a purely central workflow
|
|
(i.e. the fetch source is equal to the push destination),
|
|
`upstream` is probably what you want. Possible values are:
|
|
+
|
|
--
|
|
|
|
* `nothing` - do not push anything (error out) unless a refspec is
|
|
given. This is primarily meant for people who want to
|
|
avoid mistakes by always being explicit.
|
|
|
|
* `current` - push the current branch to update a branch with the same
|
|
name on the receiving end. Works in both central and non-central
|
|
workflows.
|
|
|
|
* `upstream` - push the current branch back to the branch whose
|
|
changes are usually integrated into the current branch (which is
|
|
called `@{upstream}`). This mode only makes sense if you are
|
|
pushing to the same repository you would normally pull from
|
|
(i.e. central workflow).
|
|
|
|
* `tracking` - This is a deprecated synonym for `upstream`.
|
|
|
|
* `simple` - in centralized workflow, work like `upstream` with an
|
|
added safety to refuse to push if the upstream branch's name is
|
|
different from the local one.
|
|
+
|
|
When pushing to a remote that is different from the remote you normally
|
|
pull from, work as `current`. This is the safest option and is suited
|
|
for beginners.
|
|
+
|
|
This mode has become the default in Git 2.0.
|
|
|
|
* `matching` - push all branches having the same name on both ends.
|
|
This makes the repository you are pushing to remember the set of
|
|
branches that will be pushed out (e.g. if you always push 'maint'
|
|
and 'master' there and no other branches, the repository you push
|
|
to will have these two branches, and your local 'maint' and
|
|
'master' will be pushed there).
|
|
+
|
|
To use this mode effectively, you have to make sure _all_ the
|
|
branches you would push out are ready to be pushed out before
|
|
running 'git push', as the whole point of this mode is to allow you
|
|
to push all of the branches in one go. If you usually finish work
|
|
on only one branch and push out the result, while other branches are
|
|
unfinished, this mode is not for you. Also this mode is not
|
|
suitable for pushing into a shared central repository, as other
|
|
people may add new branches there, or update the tip of existing
|
|
branches outside your control.
|
|
+
|
|
This used to be the default, but not since Git 2.0 (`simple` is the
|
|
new default).
|
|
|
|
--
|
|
|
|
push.followTags::
|
|
If set to true enable `--follow-tags` option by default. You
|
|
may override this configuration at time of push by specifying
|
|
`--no-follow-tags`.
|
|
|
|
push.gpgSign::
|
|
May be set to a boolean value, or the string 'if-asked'. A true
|
|
value causes all pushes to be GPG signed, as if `--signed` is
|
|
passed to linkgit:git-push[1]. The string 'if-asked' causes
|
|
pushes to be signed if the server supports it, as if
|
|
`--signed=if-asked` is passed to 'git push'. A false value may
|
|
override a value from a lower-priority config file. An explicit
|
|
command-line flag always overrides this config option.
|
|
|
|
push.pushOption::
|
|
When no `--push-option=<option>` argument is given from the
|
|
command line, `git push` behaves as if each <value> of
|
|
this variable is given as `--push-option=<value>`.
|
|
+
|
|
This is a multi-valued variable, and an empty value can be used in a
|
|
higher priority configuration file (e.g. `.git/config` in a
|
|
repository) to clear the values inherited from a lower priority
|
|
configuration files (e.g. `$HOME/.gitconfig`).
|
|
+
|
|
----
|
|
|
|
Example:
|
|
|
|
/etc/gitconfig
|
|
push.pushoption = a
|
|
push.pushoption = b
|
|
|
|
~/.gitconfig
|
|
push.pushoption = c
|
|
|
|
repo/.git/config
|
|
push.pushoption =
|
|
push.pushoption = b
|
|
|
|
This will result in only b (a and c are cleared).
|
|
|
|
----
|
|
|
|
push.recurseSubmodules::
|
|
Make sure all submodule commits used by the revisions to be pushed
|
|
are available on a remote-tracking branch. If the value is 'check'
|
|
then Git will verify that all submodule commits that changed in the
|
|
revisions to be pushed are available on at least one remote of the
|
|
submodule. If any commits are missing, the push will be aborted and
|
|
exit with non-zero status. If the value is 'on-demand' then all
|
|
submodules that changed in the revisions to be pushed will be
|
|
pushed. If on-demand was not able to push all necessary revisions
|
|
it will also be aborted and exit with non-zero status. If the value
|
|
is 'no' then default behavior of ignoring submodules when pushing
|
|
is retained. You may override this configuration at time of push by
|
|
specifying '--recurse-submodules=check|on-demand|no'.
|
|
If not set, 'no' is used by default, unless 'submodule.recurse' is
|
|
set (in which case a 'true' value means 'on-demand').
|
|
|
|
push.useForceIfIncludes::
|
|
If set to "true", it is equivalent to specifying
|
|
`--force-if-includes` as an option to linkgit:git-push[1]
|
|
in the command line. Adding `--no-force-if-includes` at the
|
|
time of push overrides this configuration setting.
|