git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH 2/6] config doc: rewrite push.default section
Date: Sun, 23 Jun 2013 21:33:04 -0700	[thread overview]
Message-ID: <1372048388-16742-3-git-send-email-gitster@pobox.com> (raw)
In-Reply-To: <1372048388-16742-1-git-send-email-gitster@pobox.com>

From: Ramkumar Ramachandra <artagnon@gmail.com>

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>
---
 Documentation/config.txt | 72 +++++++++++++++++++++++++++++-------------------
 1 file changed, 44 insertions(+), 28 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7fd4035..5d8ff1a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -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
-- 
1.8.3.1-721-g0a353d3

  parent reply	other threads:[~2013-06-24  4:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-24  4:33 [PATCH 0/6] Reroll of rr/triangular-push-fix Junio C Hamano
2013-06-24  4:33 ` [PATCH 1/6] t/t5528-push-default: remove redundant test_config lines Junio C Hamano
2013-06-24  4:33 ` Junio C Hamano [this message]
2013-06-24  4:33 ` [PATCH 3/6] push: change `simple` to accommodate triangular workflows Junio C Hamano
2013-06-24  6:58   ` Johan Herland
2013-06-24  7:43     ` Junio C Hamano
2013-06-24  7:46     ` Ramkumar Ramachandra
2013-06-24  8:48       ` Johan Herland
2013-06-24 14:13         ` Ramkumar Ramachandra
2013-06-24  7:59     ` Junio C Hamano
2013-06-24  8:48       ` Johan Herland
2013-06-24  4:33 ` [PATCH 4/6] t/t5528-push-default: generalize test_push_* Junio C Hamano
2013-06-24  6:58   ` Johan Herland
2013-06-24  7:28     ` Junio C Hamano
2013-06-24  8:33       ` Johan Herland
2013-06-24  8:44         ` Eric Sunshine
2013-06-24  9:45           ` Johan Herland
2013-06-24 17:21       ` Junio C Hamano
2013-06-24  4:33 ` [PATCH 5/6] t/t5528-push-default: test pushdefault workflows Junio C Hamano
2013-06-24  4:33 ` [PATCH 6/6] push: honor branch.*.push Junio C Hamano
2013-06-24  6:58   ` Johan Herland
2013-06-24  7:47     ` Junio C Hamano
2013-06-24  7:58   ` Ramkumar Ramachandra
2013-06-24  8:17     ` Junio C Hamano
2013-06-24 14:19       ` Ramkumar Ramachandra
2013-06-24 15:23         ` Johan Herland
2013-06-24 16:08           ` Junio C Hamano
2013-06-24 15:41         ` Junio C Hamano
2013-06-24 16:09           ` Ramkumar Ramachandra
2013-06-24 16:53             ` Junio C Hamano
2013-06-24 17:13               ` Ramkumar Ramachandra
2013-06-24 18:19                 ` Junio C Hamano
2013-06-24 18:23                   ` Ramkumar Ramachandra
2013-06-24  7:21 ` [PATCH 0/6] Reroll of rr/triangular-push-fix Ramkumar Ramachandra
2013-06-24  8:12   ` Junio C Hamano
2013-06-24 13:51     ` Ramkumar Ramachandra
  -- strict thread matches above, loose matches on Subject: below --
2013-06-19 11:11 [PATCH 0/6] push.default in the triangular world Ramkumar Ramachandra
2013-06-19 11:11 ` [PATCH 2/6] config doc: rewrite push.default section Ramkumar Ramachandra
2013-06-19 19:55   ` Junio C Hamano
2013-06-20  3:27     ` Junio C Hamano
2013-06-20  7:35       ` Johan Herland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1372048388-16742-3-git-send-email-gitster@pobox.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).