* mm/phrase-remote-tracking:
git-branch.txt: mention --set-upstream as a way to change upstream configuration
user-manual: remote-tracking can be checked out, with detached HEAD
user-manual.txt: explain better the remote(-tracking) branch terms
Change incorrect "remote branch" to "remote tracking branch" in C code
Change incorrect uses of "remote branch" meaning "remote-tracking"
Change "tracking branch" to "remote-tracking branch"
everyday.txt: change "tracking branch" to "remote-tracking branch"
Change remote tracking to remote-tracking in non-trivial places
Replace "remote tracking" with "remote-tracking"
Better "Changed but not updated" message in git-status
@ -180,12 +180,12 @@ directory; clone from it to start a repository on the satellite
@@ -180,12 +180,12 @@ directory; clone from it to start a repository on the satellite
machine.
<2> clone sets these configuration variables by default.
It arranges `git pull` to fetch and store the branches of mothership
machine to local `remotes/origin/*` tracking branches.
machine to local `remotes/origin/*` remote-tracking branches.
<3> arrange `git push` to push local `master` branch to
`remotes/satellite/master` branch of the mothership machine.
<4> push will stash our work away on `remotes/satellite/master`
tracking branch on the mothership machine. You could use this as
a back-up method.
remote-tracking branch on the mothership machine. You could use this
as a back-up method.
<5> on mothership machine, merge the work done on the satellite
@ -37,11 +37,12 @@ Note that this will create the new branch, but it will not switch the
@@ -37,11 +37,12 @@ Note that this will create the new branch, but it will not switch the
working tree to it; use "git checkout <newbranch>" to switch to the
new branch.
When a local branch is started off a remote branch, git sets up the
When a local branch is started off a remote-tracking branch, git sets up the
branch so that 'git pull' will appropriately merge from
the remote branch. This behavior may be changed via the global
the remote-tracking branch. This behavior may be changed via the global
`branch.autosetupmerge` configuration flag. That setting can be
overridden by using the `--track` and `--no-track` options.
overridden by using the `--track` and `--no-track` options, and
changed later using `git branch --set-upstream`.
With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
If <oldbranch> had a corresponding reflog, it is renamed to match
@ -131,7 +131,7 @@ objects from the source repository into a pack in the cloned repository.
@@ -131,7 +131,7 @@ objects from the source repository into a pack in the cloned repository.
Set up a mirror of the source repository. This implies `--bare`.
Compared to `--bare`, `--mirror` not only maps local branches of the
source to local branches of the target, it maps all refs (including
remote branches, notes etc.) and sets up a refspec configuration such
remote-tracking branches, notes etc.) and sets up a refspec configuration such
that all these refs are overwritten by a `git remote update` in the
@ -26,7 +26,7 @@ The ref names and their object names of fetched refs are stored
@@ -26,7 +26,7 @@ The ref names and their object names of fetched refs are stored
in `.git/FETCH_HEAD`. This information is left for a later merge
operation done by 'git merge'.
When <refspec> stores the fetched result in tracking branches,
When <refspec> stores the fetched result in remote-tracking branches,
the tags that point at these branches are automatically
followed. This is done by first fetching from the remote using
the given <refspec>s, and if the repository has objects that are
@ -89,7 +89,7 @@ are not part of the current project most users will want to expire
@@ -89,7 +89,7 @@ are not part of the current project most users will want to expire
them sooner. This option defaults to '30 days'.
The above two configuration variables can be given to a pattern. For
example, this sets non-default expiry values only to remote tracking
example, this sets non-default expiry values only to remote-tracking
@ -26,7 +26,7 @@ With `--rebase`, it runs 'git rebase' instead of 'git merge'.
@@ -26,7 +26,7 @@ With `--rebase`, it runs 'git rebase' instead of 'git merge'.
<repository> should be the name of a remote repository as
passed to linkgit:git-fetch[1]. <refspec> can name an
arbitrary remote ref (for example, the name of a tag) or even
a collection of refs with corresponding remote tracking branches
a collection of refs with corresponding remote-tracking branches
(e.g., refs/heads/*:refs/remotes/origin/*), but usually it is
the name of a branch in the remote repository.
@ -136,7 +136,7 @@ and if there is not any such variable, the value on `URL: ` line
@@ -136,7 +136,7 @@ and if there is not any such variable, the value on `URL: ` line
in `$GIT_DIR/remotes/<origin>` file is used.
In order to determine what remote branches to fetch (and
optionally store in the tracking branches) when the command is
optionally store in the remote-tracking branches) when the command is
run without any refspec parameters on the command line, values
of the configuration variable `remote.<origin>.fetch` are
consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>`
@ -75,7 +75,7 @@ was passed.
@@ -75,7 +75,7 @@ was passed.
'rename'::
Rename the remote named <old> to <new>. All remote tracking branches and
Rename the remote named <old> to <new>. All remote-tracking branches and
configuration settings for the remote are updated.
+
In case <old> and <new> are the same, and <old> is a file under
@ -84,7 +84,7 @@ the configuration file format.
@@ -84,7 +84,7 @@ the configuration file format.
'rm'::
Remove the remote named <name>. All remote tracking branches and
Remove the remote named <name>. All remote-tracking branches and
configuration settings for the remote are removed.
'set-head'::
@ -146,7 +146,7 @@ With `-n` option, the remote heads are not queried first with
@@ -146,7 +146,7 @@ With `-n` option, the remote heads are not queried first with
'prune'::
Deletes all stale tracking branches under <name>.
Deletes all stale remote-tracking branches under <name>.
These stale branches have already been removed from the remote repository
referenced by <name>, but are still locally available in
@ -131,7 +131,7 @@ to point at the new commit.
@@ -131,7 +131,7 @@ to point at the new commit.
you have. In such these cases, you do not make a new <<def_merge,merge>>
<<def_commit,commit>> but instead just update to his
revision. This will happen frequently on a
<<def_tracking_branch,tracking branch>> of a remote
<<def_remote_tracking_branch,remote-tracking branch>> of a remote
<<def_repository,repository>>.
[[def_fetch]]fetch::
@ -260,7 +260,7 @@ This commit is referred to as a "merge commit", or sometimes just a
@@ -260,7 +260,7 @@ This commit is referred to as a "merge commit", or sometimes just a
The default upstream <<def_repository,repository>>. Most projects have
at least one upstream project which they track. By default
'origin' is used for that purpose. New upstream updates
will be fetched into remote <<def_tracking_branch,tracking branches>> named
will be fetched into remote <<def_remote_tracking_branch,remote-tracking branches>> named
origin/name-of-upstream-branch, which you can see using
`git branch -r`.
@ -349,6 +349,14 @@ This commit is referred to as a "merge commit", or sometimes just a
@@ -349,6 +349,14 @@ This commit is referred to as a "merge commit", or sometimes just a
master branch head as to-upstream branch at $URL". See also
A regular git <<def_branch,branch>> that is used to follow changes from
another <<def_repository,repository>>. A remote-tracking
branch should not contain direct modifications or have local commits
made to it. A remote-tracking branch can usually be
identified as the right-hand-side <<def_ref,ref>> in a Pull:
<<def_refspec,refspec>>.
[[def_repository]]repository::
A collection of <<def_ref,refs>> together with an
<<def_object_database,object database>> containing all objects
@ -418,14 +426,6 @@ This commit is referred to as a "merge commit", or sometimes just a
@@ -418,14 +426,6 @@ This commit is referred to as a "merge commit", or sometimes just a
that each contain very well defined concepts or small incremental yet
related changes.
[[def_tracking_branch]]tracking branch::
A regular git <<def_branch,branch>> that is used to follow changes from
another <<def_repository,repository>>. A tracking
branch should not contain direct modifications or have local commits
made to it. A tracking branch can usually be
identified as the right-hand-side <<def_ref,ref>> in a Pull:
<<def_refspec,refspec>>.
[[def_tree]]tree::
Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree
object>> together with the dependent <<def_blob_object,blob>> and tree objects
If you run "git fetch <remote>" later, the tracking branches for the
If you run "git fetch <remote>" later, the remote-tracking branches for the
named <remote> will be updated.
If you examine the file .git/config, you will see that git has added
@ -1700,7 +1711,7 @@ may wish to check the original repository for updates and merge them
@@ -1700,7 +1711,7 @@ may wish to check the original repository for updates and merge them
into your own work.
We have already seen <<Updating-a-repository-With-git-fetch,how to
keep remote tracking branches up to date>> with linkgit:git-fetch[1],
keep remote-tracking branches up to date>> with linkgit:git-fetch[1],
and how to merge two branches. So you can merge in changes from the
original repository's master branch with:
@ -1716,15 +1727,21 @@ one step:
@@ -1716,15 +1727,21 @@ one step:
$ git pull origin master
-------------------------------------------------
In fact, if you have "master" checked out, then by default "git pull"
merges from the HEAD branch of the origin repository. So often you can
In fact, if you have "master" checked out, then this branch has been
configured by "git clone" to get changes from the HEAD branch of the
origin repository. So often you can
accomplish the above with just a simple
-------------------------------------------------
$ git pull
-------------------------------------------------
More generally, a branch that is created from a remote branch will pull
This command will fetch changes from the remote branches to your
remote-tracking branches `origin/*`, and merge the default branch into
the current branch.
More generally, a branch that is created from a remote-tracking branch
will pull
by default from that branch. See the descriptions of the
branch.<name>.remote and branch.<name>.merge options in
linkgit:git-config[1], and the discussion of the `--track` option in
Linus's tree will be stored in the remote branch named origin/master,
Linus's tree will be stored in the remote-tracking branch named origin/master,
and can be updated using linkgit:git-fetch[1]; you can track other
public trees using linkgit:git-remote[1] to set up a "remote" and
linkgit:git-fetch[1] to keep them up-to-date; see
@ -2800,8 +2817,8 @@ Be aware that commits that the old version of example/master pointed at
@@ -2800,8 +2817,8 @@ Be aware that commits that the old version of example/master pointed at
may be lost, as we saw in the previous section.
[[remote-branch-configuration]]
Configuring remote branches
---------------------------
Configuring remote-tracking branches
------------------------------------
We saw above that "origin" is just a shortcut to refer to the
repository that you originally cloned from. This information is