push: new config option "push.autoSetupRemote" supports "simple" push
In some "simple" centralized workflows, users expect remote tracking
branch names to match local branch names. "git push" pushes to the
remote version/instance of the branch, and "git pull" pulls any changes
to the remote branch (changes made by the same user in another place, or
by other users).
This expectation is supported by the push.default default option "simple"
which refuses a default push for a mismatching tracking branch name, and
by the new branch.autosetupmerge option, "simple", which only sets up
remote tracking for same-name remote branches.
When a new branch has been created by the user and has not yet been
pushed (and push.default is not set to "current"), the user is prompted
with a "The current branch %s has no upstream branch" error, and
instructions on how to push and add tracking.
This error is helpful in that following the advice once per branch
"resolves" the issue for that branch forever, but inconvenient in that
for the "simple" centralized workflow, this is always the right thing to
do, so it would be better to just do it.
Support this workflow with a new config setting, push.autoSetupRemote,
which will cause a default push, when there is no remote tracking branch
configured, to push to the same-name on the remote and --set-upstream.
Also add a hint offering this new option when the "The current branch %s
has no upstream branch" error is encountered, and add corresponding tests.
Signed-off-by: Tao Klerks <tao@klerks.biz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-29 11:56:46 +02:00
|
|
|
push.autoSetupRemote::
|
|
|
|
If set to "true" assume `--set-upstream` on default push when no
|
|
|
|
upstream tracking exists for the current branch; this option
|
|
|
|
takes effect with push.default options 'simple', 'upstream',
|
|
|
|
and 'current'. It is useful if by default you want new branches
|
|
|
|
to be pushed to the default remote (like the behavior of
|
|
|
|
'push.default=current') and you also want the upstream tracking
|
|
|
|
to be set. Workflows most likely to benefit from this option are
|
|
|
|
'simple' central workflows where all branches are expected to
|
|
|
|
have the same name on the remote.
|
|
|
|
|
2018-08-22 18:06:01 +02:00
|
|
|
push.default::
|
|
|
|
Defines the action `git push` should take if no refspec is
|
2020-01-29 06:53:55 +01:00
|
|
|
given (whether from the command-line, config, or elsewhere).
|
|
|
|
Different values are well-suited for
|
2018-08-22 18:06:01 +02:00
|
|
|
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
|
2020-01-29 06:53:55 +01:00
|
|
|
given. This is primarily meant for people who want to
|
2018-08-22 18:06:01 +02:00
|
|
|
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`.
|
|
|
|
|
2021-05-31 21:32:37 +02:00
|
|
|
* `simple` - pushes the current branch with the same name on the remote.
|
2018-08-22 18:06:01 +02:00
|
|
|
+
|
2021-05-31 21:32:37 +02:00
|
|
|
If you are working on a centralized workflow (pushing to the same repository you
|
|
|
|
pull from, which is typically `origin`), then you need to configure an upstream
|
|
|
|
branch with the same name.
|
2018-08-22 18:06:01 +02:00
|
|
|
+
|
2021-05-31 21:32:37 +02:00
|
|
|
This mode is the default since Git 2.0, and is the safest option suited for
|
|
|
|
beginners.
|
2018-08-22 18:06:01 +02:00
|
|
|
|
|
|
|
* `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`).
|
|
|
|
+
|
2020-02-18 22:25:37 +01:00
|
|
|
----
|
2018-08-22 18:06:01 +02:00
|
|
|
|
|
|
|
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).
|
|
|
|
|
2020-02-18 22:25:37 +01:00
|
|
|
----
|
2018-08-22 18:06:01 +02:00
|
|
|
|
|
|
|
push.recurseSubmodules::
|
Doc: document push.recurseSubmodules=only
Git learned pushing submodules without pushing the superproject by
the user specifying --recurse-submodules=only through 6c656c3fe4
("submodules: add RECURSE_SUBMODULES_ONLY value", 2016-12-20) and
225e8bf778 ("push: add option to push only submodules", 2016-12-20).
For users who use this feature regularly, it is desirable to have an
equivalent configuration.
It turns out that such a configuration (push.recurseSubmodules=only) is
already supported, even though it is neither documented nor mentioned
in the commit messages, due to the way the --recurse-submodules=only
feature was implemented (a function used to parse --recurse-submodules
was updated to support "only", but that same function is used to parse
push.recurseSubmodules too). What is left is to document it and test it,
which is what this commit does.
There is a possible point of confusion when recursing into a submodule
that itself has the push.recurseSubmodules=only configuration, because
if a repository has only its submodules pushed and not itself, its
superproject can never be pushed. Therefore, treat such configurations
as being "on-demand", and print a warning message.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
2022-11-14 22:37:12 +01:00
|
|
|
May be "check", "on-demand", "only", or "no", with the same behavior
|
|
|
|
as that of "push --recurse-submodules".
|
2020-04-06 15:57:08 +02:00
|
|
|
If not set, 'no' is used by default, unless 'submodule.recurse' is
|
|
|
|
set (in which case a 'true' value means 'on-demand').
|
2020-10-03 14:10:46 +02:00
|
|
|
|
|
|
|
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.
|
2021-05-04 23:16:02 +02:00
|
|
|
|
|
|
|
push.negotiate::
|
|
|
|
If set to "true", attempt to reduce the size of the packfile
|
|
|
|
sent by rounds of negotiation in which the client and the
|
|
|
|
server attempt to find commits in common. If "false", Git will
|
|
|
|
rely solely on the server's ref advertisement to find commits
|
|
|
|
in common.
|
2022-06-17 21:06:19 +02:00
|
|
|
|
|
|
|
push.useBitmaps::
|
|
|
|
If set to "false", disable use of bitmaps for "git push" even if
|
|
|
|
`pack.useBitmaps` is "true", without preventing other git operations
|
|
|
|
from using bitmaps. Default is true.
|