From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH v2 5/9] fetch doc: on pulling multiple refspecs
Date: Tue, 3 Jun 2014 15:16:28 -0700 [thread overview]
Message-ID: <1401833792-2486-6-git-send-email-gitster@pobox.com> (raw)
In-Reply-To: <1401833792-2486-1-git-send-email-gitster@pobox.com>
Replace desription of old-style "Pull:" lines in remotes/
configuration with modern remote.*.fetch variables.
As this note applies only to "git pull", enable it only
in git-pull manual page.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/pull-fetch-param.txt | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index 40f8687..25af2ce 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -34,22 +34,26 @@ will be needed for such branches. There is no way to
determine or declare that a branch will be made available
in a repository with this behavior; the pulling user simply
must know this is the expected usage pattern for a branch.
+ifdef::git-pull[]
+
[NOTE]
There is a difference between listing multiple <refspec>
directly on 'git pull' command line and having multiple
-`Pull:` <refspec> lines for a <repository> and running
+`remote.<repository>.fetch` entries in your configuration
+for a <repository> and running
'git pull' command without any explicit <refspec> parameters.
<refspec> listed explicitly on the command line are always
merged into the current branch after fetching. In other words,
if you list more than one remote refs, you would be making
-an Octopus. While 'git pull' run without any explicit <refspec>
-parameter takes default <refspec>s from `Pull:` lines, it
+an Octopus merge. On the other hand, 'git pull' that is run
+without any explicit <refspec> parameter takes default
+<refspec>s from `remote.<repository>.fetch` configuration, it
merges only the first <refspec> found into the current branch,
-after fetching all the remote refs. This is because making an
+after fetching all the remote refs specified. This is because making an
Octopus from remote refs is rarely done, while keeping track
of multiple remote heads in one-go by fetching more than one
is often useful.
+endif::git-pull[]
+
Some short-cut notations are also supported.
+
--
2.0.0-511-g1433423
next prev parent reply other threads:[~2014-06-03 22:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-03 22:16 [PATCH v2 0/9] Clarify two uses of remote.*.fetch Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 1/9] fetch doc: update introductory part for clarity Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 2/9] fetch doc: move FETCH_HEAD material lower and add an example Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 3/9] fetch doc: update note on '+' in front of the refspec Junio C Hamano
2014-06-18 7:56 ` Michael Haggerty
2014-06-03 22:16 ` [PATCH v2 4/9] fetch doc: remove notes on outdated "mixed layout" Junio C Hamano
2014-06-03 22:16 ` Junio C Hamano [this message]
2014-06-04 14:44 ` [PATCH v2 5/9] fetch doc: on pulling multiple refspecs Marc Branchaud
2014-06-03 22:16 ` [PATCH v2 6/9] fetch doc: update refspec format description Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 7/9] fetch doc: remove "short-cut" section Junio C Hamano
2014-06-04 14:46 ` Marc Branchaud
2014-06-03 22:16 ` [PATCH v2 8/9] fetch doc: add a section on configured remote-tracking branches Junio C Hamano
2014-06-04 14:55 ` Marc Branchaud
2014-06-04 22:17 ` Junio C Hamano
2014-06-05 15:29 ` Marc Branchaud
2014-06-05 15:40 ` [PATCH] docs: Explain the purpose of fetch's and pull's <refspec> parameter Marc Branchaud
2014-06-05 22:12 ` Junio C Hamano
2014-06-11 14:24 ` Marc Branchaud
2014-06-03 22:16 ` [PATCH v2 9/9] fetch: allow explicit --refmap to override configuration Junio C Hamano
2014-06-04 15:01 ` Marc Branchaud
2014-06-04 22:28 ` Junio C Hamano
2014-06-05 15:45 ` Marc Branchaud
2014-06-05 18:36 ` Junio C Hamano
2014-06-18 12:21 ` Michael Haggerty
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=1401833792-2486-6-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).