зеркало из https://github.com/microsoft/git.git
config doc: rewrite push.default section
4d35924e
(Merge branch 'rr/triangle', 2013-04-07) introduced support
for triangular workflows, but the push.default values still assume
central workflows.
Rewrite the descriptions of `nothing`, `current`, `upstream` and
`matching` for greater clarity, and explicitly explain how they
should behave in triangular workflows.
Leave `simple` as it is for the moment, as we plan to change its
meaning to accommodate triangular workflows in a later patch.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Родитель
3cb8a5ff17
Коммит
87a70e4ce8
|
@ -1826,39 +1826,55 @@ pull.twohead::
|
|||
The default merge strategy to use when pulling a single branch.
|
||||
|
||||
push.default::
|
||||
Defines the action `git push` should take if no refspec is given
|
||||
on the command line, no refspec is configured in the remote, and
|
||||
no refspec is implied by any of the options given on the command
|
||||
line. Possible values are:
|
||||
Defines the action `git push` should take if no refspec is
|
||||
explicitly given. 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.
|
||||
* `matching` - push all branches having the same name in both ends.
|
||||
This is for those who prepare all the branches into a publishable
|
||||
shape and then push them out with a single command. It is not
|
||||
appropriate for pushing into a repository shared by multiple users,
|
||||
since locally stalled branches will attempt a non-fast forward push
|
||||
if other users updated the branch.
|
||||
+
|
||||
This is currently the default, but Git 2.0 will change the default
|
||||
to `simple`.
|
||||
* `upstream` - push the current branch to its upstream branch
|
||||
(`tracking` is a deprecated synonym for this).
|
||||
With this, `git push` will update the same remote ref as the one which
|
||||
is merged by `git pull`, making `push` and `pull` symmetrical.
|
||||
See "branch.<name>.merge" for how to configure the upstream branch.
|
||||
|
||||
* `nothing` - do not push anything (error out) unless a refspec is
|
||||
explicitly 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).
|
||||
|
||||
* `simple` - like `upstream`, but refuses to push if the upstream
|
||||
branch's name is different from the local one. This is the safest
|
||||
option and is well-suited for beginners. It will become the default
|
||||
in Git 2.0.
|
||||
* `current` - push the current branch to a branch of the same name.
|
||||
--
|
||||
option and is well-suited for beginners.
|
||||
+
|
||||
The `simple`, `current` and `upstream` modes are for those who want to
|
||||
push out a single branch after finishing work, even when the other
|
||||
branches are not yet ready to be pushed out. If you are working with
|
||||
other people to push into the same shared repository, you would want
|
||||
to use one of these.
|
||||
This mode will 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 is currently the default, but Git 2.0 will change the default
|
||||
to `simple`.
|
||||
|
||||
--
|
||||
|
||||
rebase.stat::
|
||||
Whether to show a diffstat of what changed upstream since the last
|
||||
|
|
Загрузка…
Ссылка в новой задаче