Documentation: talk about guts of merge in tutorial.
[gitweb.git] / Documentation / pull-fetch-param.txt
index 2a7131874be370579f2f1ef4a72074b5d8b86141..5c2888e16362798a494b146036e721a19f622517 100644 (file)
@@ -17,12 +17,12 @@ file in `$GIT_DIR/remotes` directory can be given; the
 named file should be in the following format:
 +
        URL: one of the above URL format
-       Push: <refspec>...
-       Pull: <refspec>...
+       Push: <refspec>
+       Pull: <refspec>
 +
 When such a short-hand is specified in place of
 <repository> without <refspec> parameters on the command
-line, <refspec>... specified on `Push:` lines or `Pull:`
+line, <refspec> specified on `Push:` lines or `Pull:`
 lines are used for `git-push` and `git-fetch`/`git-pull`,
 respectively.  Multiple `Push:` and and `Pull:` lines may
 be specified for additional branch mappings.
@@ -82,14 +82,35 @@ must know this is the expected usage pattern for a branch.
 [NOTE]
 You never do your own development on branches that appear
 on the right hand side of a <refspec> colon on `Pull:` lines;
-they are to be updated by `git-fetch`.  The corollary is that
-a local branch should be introduced and named on a <refspec>
-right-hand-side if you intend to do development derived from
-that branch.
-This leads to the common `Pull: master:origin` mapping of a
-remote `master` branch to a local `origin` branch, which
-is then merged to a local development branch, again typically
-named `master`.
+they are to be updated by `git-fetch`.  If you intend to do
+development derived from a remote branch `B`, have a `Pull:`
+line to track it (i.e. `Pull: B:remote-B`), and have a separate
+branch `my-B` to do your development on top of it.  The latter
+is created by `git branch my-B remote-B` (or its equivalent `git
+checkout -b my-B remote-B`).  Run `git fetch` to keep track of
+the progress of the remote side, and when you see something new
+on the remote branch, merge it into your development branch with
+`git pull . remote-B`, while you are on `my-B` branch.
+The common `Pull: master:origin` mapping of a remote `master`
+branch to a local `origin` branch, which is then merged to a
+ocal development branch, again typically named `master`, is made
+when you run `git clone` for you to follow this pattern.
++
+[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
+`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
+merges only the first <refspec> found into the current branch,
+after fetching all the remote refs.  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.
 +
 Some short-cut notations are also supported.
 +