-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
+local 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.