Error in git book or I misunderstood?

Question

Here you can read:

Tracking Branches Checking out a local branch from a remote branch automatically creates what is called a tracking branch. Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type git push, Git automatically knows which server and branch to push to. Also, running git pull while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch.

Instead of merges in the corresponding remote branch shouldn't day merge in the corresponding local branch?

Answer 1

You have mistaken the italics here. The verb is "merges in" with emphasis on in. You read it as "merges into". Instead, read it as "merges in from the corresponding remote branch".

Answer 2

TL;DR:

Also, running git pull while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch.

That should read as:

The git pull will update a "remote tracking branch", and merge those updates in a local branch tracking said remote tracking branch.

See the next section for an explanation of all those different "tracking" elements.

---

Note that the term "track" has been part of the most confusing ones in git, from Mark Longair blog post "The most confusing git terminology".

“track” and “tracking”

1/ “track” as in “untracked files”

To say that a file is tracked in the repository appears to mean that it is either present in the index or exists in the commit pointed to by HEAD.
You see this usage most often in the output of “git status”, where it will list “untracked files”:

# On branch master
# Untracked files:

2. “track” as in “remote-tracking branch”

As a bit of background, you can think of a remote-tracking branch as a local cache of the state of a branch in a remote repository.
The most commonly seen example is origin/master, or, to name that ref in full, refs/remotes/origin/master.
Such branches are usually updated by git fetch.

The sense of “track” in the phrase “remote-tracking branch” is indicating that the remote-tracking branch is tracking the state of the branch in the remote repository the last time that remote-tracking branch was updated.
So, you might say that refs/remotes/origin/master is tracking the state of the branch master in origin.

The “tracking” here is defined by the refspec in the config variable remote.<remote-name>.fetch and the URL in the config variable remote.<remote-name>.url.

3. “track” as in “git branch –track foo origin/bar” or: “Branch foo set up to track remote branch bar from origin”

Again, if you want to do some work on a branch from a remote repository, but want to keep your work separate from everything else in your repository, you’ll typically use a command like the following (or one of its many “Do What I Mean” equivalents):

git checkout --track -b foo origin/bar

The sense of “track” both in the command and the output is distinct from the previous sense – it means that config options have been set that associate your new local branch with another branch in the remote repository.
The documentation sometimes refers to this relationship as making bar in origin “upstream” of foo.
This “upstream” association is very useful, in fact:

• it enables nice features like being able to just type git pull while you’re on branch foo in order to fetch from origin and then merge from origin/bar.
• It’s also how you get helpful messages about the state of your branch relative to the remote-tracking branch, like “Your branch foo is 24 commits ahead of origin/bar and can be fast-forwarded”.

The tracking here is defined by config variables branch.<branch-name>.remote and branch.<branch-name>.merge.

Answer 3

If you're talking about the last sentence, I believe that to be correct.

For pushing:
Corresponding local branch pushes to remote branch.

For Fetching:
Corresponding remote branch pushes to local branch.

That's how I would interpret it.