undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

config doc: rewrite push.default section

Browse Source 
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:
Ramkumar Ramachandra 2013-06-19 16:41:40 +05:30 committed by Junio C Hamano
parent 3cb8a5ff17
commit 87a70e4ce8
1 changed files with 44 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

72
Documentation/config.txt
View File

@ -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