Change "tracking branch" to "remote-tracking branch"
One more step towards consistancy. We change the documentation and the C code in a single patch, since the only instances in the C code are in comment and usage strings. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Matthieu Moy committed
Nov 2, 2010 at 16:31 UTC
8b3f3f84b27e6bbac1b1558166b44431a8e78bb1
10 files changed
+24
-24
Documentation/config.txt
+2
-2
@@ -680,7 +680,7 @@ color.branch::
680
color.branch.<slot>::
681
Use customized color for branch coloration. `<slot>` is one of
682
`current` (the current branch), `local` (a local branch),
683
- `remote` (a tracking branch in refs/remotes/), `plain` (other
683
+ `remote` (a remote-tracking branch in refs/remotes/), `plain` (other
684
refs).
685
+
686
The value for these configuration variables is a list of colors (at most
@@ -1102,7 +1102,7 @@ gui.newbranchtemplate::
1102
linkgit:git-gui[1].
1103
1104
gui.pruneduringfetch::
1105
- "true" if linkgit:git-gui[1] should prune tracking branches when
1105
+ "true" if linkgit:git-gui[1] should prune remote-tracking branches when
1106
performing a fetch. The default value is "false".
1107
1108
gui.trustmtime::
Documentation/git-fetch.txt
+1
-1
@@ -26,7 +26,7 @@ The ref names and their object names of fetched refs are stored
26
in `.git/FETCH_HEAD`. This information is left for a later merge
27
operation done by 'git merge'.
28
29
-When <refspec> stores the fetched result in tracking branches,
29
+When <refspec> stores the fetched result in remote-tracking branches,
30
the tags that point at these branches are automatically
31
followed. This is done by first fetching from the remote using
32
the given <refspec>s, and if the repository has objects that are
Documentation/git-pull.txt
+3
-3
@@ -134,7 +134,7 @@ and if there is not any such variable, the value on `URL: ` line
134
in `$GIT_DIR/remotes/<origin>` file is used.
135
136
In order to determine what remote branches to fetch (and
137
-optionally store in the tracking branches) when the command is
137
+optionally store in the remote-tracking branches) when the command is
138
run without any refspec parameters on the command line, values
139
of the configuration variable `remote.<origin>.fetch` are
140
consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>`
@@ -147,9 +147,9 @@ refs/heads/*:refs/remotes/origin/*
147
------------
148
149
A globbing refspec must have a non-empty RHS (i.e. must store
150
-what were fetched in tracking branches), and its LHS and RHS
150
+what were fetched in remote-tracking branches), and its LHS and RHS
151
must end with `/*`. The above specifies that all remote
152
-branches are tracked using tracking branches in
152
+branches are tracked using remote-tracking branches in
153
`refs/remotes/origin/` hierarchy under the same name.
154
155
The rule to determine which remote branch to merge after
Documentation/git-remote.txt
+1
-1
@@ -146,7 +146,7 @@ With `-n` option, the remote heads are not queried first with
146
147
'prune'::
148
149
-Deletes all stale tracking branches under <name>.
149
+Deletes all stale remote-tracking branches under <name>.
150
These stale branches have already been removed from the remote repository
151
referenced by <name>, but are still locally available in
152
"remotes/<name>".
Documentation/git-tag.txt
+2
-2
@@ -177,7 +177,7 @@ On Automatic following
177
~~~~~~~~~~~~~~~~~~~~~~
178
179
If you are following somebody else's tree, you are most likely
180
-using tracking branches (`refs/heads/origin` in traditional
180
+using remote-tracking branches (`refs/heads/origin` in traditional
181
layout, or `refs/remotes/origin/master` in the separate-remote
182
layout). You usually want the tags from the other end.
183
@@ -232,7 +232,7 @@ this case.
232
It may well be that among networking people, they may want to
233
exchange the tags internal to their group, but in that workflow
234
they are most likely tracking with each other's progress by
235
-having tracking branches. Again, the heuristic to automatically
235
+having remote-tracking branches. Again, the heuristic to automatically
236
follow such tags is a good thing.
237
238
Documentation/glossary-content.txt
+10
-10
@@ -131,7 +131,7 @@ to point at the new commit.
131
you have. In such these cases, you do not make a new <<def_merge,merge>>
132
<<def_commit,commit>> but instead just update to his
133
revision. This will happen frequently on a
134
- <<def_tracking_branch,tracking branch>> of a remote
134
+ <<def_remote_tracking_branch,remote-tracking branch>> of a remote
135
<<def_repository,repository>>.
136
137
[[def_fetch]]fetch::
@@ -260,7 +260,7 @@ This commit is referred to as a "merge commit", or sometimes just a
260
The default upstream <<def_repository,repository>>. Most projects have
261
at least one upstream project which they track. By default
262
'origin' is used for that purpose. New upstream updates
263
- will be fetched into remote <<def_tracking_branch,tracking branches>> named
263
+ will be fetched into remote <<def_remote_tracking_branch,remote-tracking branches>> named
264
origin/name-of-upstream-branch, which you can see using
265
`git branch -r`.
266
@@ -349,6 +349,14 @@ This commit is referred to as a "merge commit", or sometimes just a
349
master branch head as to-upstream branch at $URL". See also
350
linkgit:git-push[1].
351
352
+[[def_remote_tracking_branch]]remote-tracking branch::
353
+ A regular git <<def_branch,branch>> that is used to follow changes from
354
+ another <<def_repository,repository>>. A remote-tracking
355
+ branch should not contain direct modifications or have local commits
356
+ made to it. A remote-tracking branch can usually be
357
+ identified as the right-hand-side <<def_ref,ref>> in a Pull:
358
+ <<def_refspec,refspec>>.
359
+
360
[[def_repository]]repository::
361
A collection of <<def_ref,refs>> together with an
362
<<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
426
that each contain very well defined concepts or small incremental yet
427
related changes.
428
421
-[[def_tracking_branch]]tracking branch::
422
- A regular git <<def_branch,branch>> that is used to follow changes from
423
- another <<def_repository,repository>>. A tracking
424
- branch should not contain direct modifications or have local commits
425
- made to it. A tracking branch can usually be
426
- identified as the right-hand-side <<def_ref,ref>> in a Pull:
427
- <<def_refspec,refspec>>.
428
-
429
[[def_tree]]tree::
430
Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree
431
object>> together with the dependent <<def_blob_object,blob>> and tree objects
Documentation/user-manual.txt
+1
-1
@@ -435,7 +435,7 @@ linux-nfs/master
435
origin/master
436
-------------------------------------------------
437
438
-If you run "git fetch <remote>" later, the tracking branches for the
438
+If you run "git fetch <remote>" later, the remote-tracking branches for the
439
named <remote> will be updated.
440
441
If you examine the file .git/config, you will see that git has added
builtin/checkout.c
+1
-1
@@ -784,7 +784,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
784
* between A and B, A...B names that merge base.
785
*
786
* With no paths, if <something> is _not_ a commit, no -t nor -b
787
- * was given, and there is a tracking branch whose name is
787
+ * was given, and there is a remote-tracking branch whose name is
788
* <something> in one and only one remote, then this is a short-hand
789
* to fork local <something> from that remote-tracking branch.
790
*
builtin/fetch.c
+2
-2
@@ -52,7 +52,7 @@ static struct option builtin_fetch_options[] = {
52
OPT_SET_INT('n', NULL, &tags,
53
"do not fetch all tags (--no-tags)", TAGS_UNSET),
54
OPT_BOOLEAN('p', "prune", &prune,
55
- "prune tracking branches no longer on remote"),
55
+ "prune remote-tracking branches no longer on remote"),
56
OPT_BOOLEAN(0, "dry-run", &dry_run,
57
"dry run"),
58
OPT_BOOLEAN('k', "keep", &keep, "keep downloaded pack"),
@@ -98,7 +98,7 @@ static void add_merge_config(struct ref **head,
98
continue;
99
100
/*
101
- * Not fetched to a tracking branch? We need to fetch
101
+ * Not fetched to a remote-tracking branch? We need to fetch
102
* it anyway to allow this branch's "branch.$name.merge"
103
* to be honored by 'git pull', but we do not have to
104
* fail if branch.$name.merge is misconfigured to point
remote.c
+1
-1
@@ -493,7 +493,7 @@ static void read_config(void)
493
}
494
495
/*
496
- * We need to make sure the tracking branches are well formed, but a
496
+ * We need to make sure the remote-tracking branches are well formed, but a
497
* wildcard refspec in "struct refspec" must have a trailing slash. We
498
* temporarily drop the trailing '/' while calling check_ref_format(),
499
* and put it back. The caller knows that a CHECK_REF_FORMAT_ONELEVEL