Following the discussion in
http://thread.gmane.org/gmane.comp.version-control.git/159287/http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=159288
this is an attempt to be more consistant in the terminology used in Git.
The first patch fixes git status's "changed but not updated", and the
rest tries to use "remote-tracking branch" consistantly. This
essentially changes the doc, and also does slight modifications to the
code. This changes error message, and maybe more controversially the
generated merge messages (in a separate patch in case this is too
controversial).
I've tried splitting this into systematic changes to ease review, but
patches should be applicable in any order (i.e. Junio: if you find
some of the patches good and uncontroversial, you can pick them
right away).
Patch "user-manual.txt: explain better the remote(-tracking) branch
terms" comes last, and adds a few sentences to make the distinction
between remote, remote branch, remote-tracking branches explicit.
Hopefully, this should avoid future users to have the same
difficulties as Thore ;-).
The last 2 patches are minor things I noticed while going through the
docs, but are essentially unrelated.
I'll be busy next week, so if anyone else wants to pick this patch
serie and update it according to list review, he's welcome. Otherwise,
it may have to wait.
Matthieu Moy (11):
Better "Changed but not updated" message in git-status
Remplace "remote tracking" with "remote-tracking"
Change remote tracking to remote-tracking in non-trivial places
Change "tracking branch" to "remote-tracking branch"
Change "tracking branch" to "remote-tracking branch" in C code
Change incorrect uses of "remote branch" meaning "remote-tracking"
Change incorrect "remote branch" to "remote tracking branch" in C
code
Use 'remote-tracking branch' in generated merge messages
user-manual.txt: explain better the remote(-tracking) branch terms
git-branch.txt: mention --set-upstream as a way to change upstream
configuration
git-http-push.txt: fix typo (branch -> branches)
Documentation/config.txt | 13 ++++++-----
Documentation/everyday.txt | 6 ++--
Documentation/fetch-options.txt | 2 +-
Documentation/git-branch.txt | 14 +++++++-----
Documentation/git-checkout.txt | 2 +-
Documentation/git-clone.txt | 2 +-
Documentation/git-describe.txt | 2 +-
Documentation/git-fetch.txt | 2 +-
Documentation/git-gc.txt | 6 ++--
Documentation/git-http-push.txt | 2 +-
Documentation/git-log.txt | 2 +-
Documentation/git-pull.txt | 8 +++---
Documentation/git-remote.txt | 6 ++--
Documentation/git-tag.txt | 4 +-
Documentation/gittutorial-2.txt | 2 +-
Documentation/gittutorial.txt | 6 ++--
Documentation/glossary-content.txt | 8 +++---
Documentation/rev-list-options.txt | 2 +-
Documentation/user-manual.txt | 22 +++++++++++++++-----
branch.h | 2 +-
builtin/checkout.c | 4 +-
builtin/fetch.c | 6 ++--
builtin/fmt-merge-msg.c | 6 ++--
builtin/merge.c | 2 +-
builtin/remote.c | 6 ++--
contrib/examples/builtin-fetch--tool.c | 2 +-
remote.c | 2 +-
t/t1507-rev-parse-upstream.sh | 2 +-
t/t3409-rebase-preserve-merges.sh | 2 +-
t/t5400-send-pack.sh | 2 +-
t/t5505-remote.sh | 6 ++--
t/t5513-fetch-track.sh | 2 +-
t/t7508-status.sh | 34 ++++++++++++++++----------------
t/t7608-merge-messages.sh | 4 +-
wt-status.c | 2 +-
35 files changed, 104 insertions(+), 91 deletions(-)
--
1.7.3.2.537.g7e355
@@ -680,7 +680,7 @@ color.branch:: color.branch.<slot>:: Use customized color for branch coloration. `<slot>` is one of `current` (the current branch), `local` (a local branch),- `remote` (a tracking branch in refs/remotes/), `plain` (other+ `remote` (a remote-tracking branch in refs/remotes/), `plain` (other refs). + The value for these configuration variables is a list of colors (at most
@@ -1102,7 +1102,7 @@ gui.newbranchtemplate:: linkgit:git-gui[1]. gui.pruneduringfetch::- "true" if linkgit:git-gui[1] should prune tracking branches when+ "true" if linkgit:git-gui[1] should prune remote-tracking branches when performing a fetch. The default value is "false". gui.trustmtime::
@@ -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
@@ -134,7 +134,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>`
@@ -147,9 +147,9 @@ refs/heads/*:refs/remotes/origin/* ------------ A globbing refspec must have a non-empty RHS (i.e. must store-what were fetched in tracking branches), and its LHS and RHS+what were fetched in remote-tracking branches), and its LHS and RHS must end with `/*`. The above specifies that all remote-branches are tracked using tracking branches in+branches are tracked using remote-tracking branches in `refs/remotes/origin/` hierarchy under the same name. The rule to determine which remote branch to merge after
@@ -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 "remotes/<name>".
@@ -177,7 +177,7 @@ On Automatic following ~~~~~~~~~~~~~~~~~~~~~~ If you are following somebody else's tree, you are most likely-using tracking branches (`refs/heads/origin` in traditional+using remote-tracking branches (`refs/heads/origin` in traditional layout, or `refs/remotes/origin/master` in the separate-remote layout). You usually want the tags from the other end.
@@ -232,7 +232,7 @@ this case. It may well be that among networking people, they may want to exchange the tags internal to their group, but in that workflow they are most likely tracking with each other's progress by-having tracking branches. Again, the heuristic to automatically+having remote-tracking branches. Again, the heuristic to automatically follow such tags is a good thing.
@@ -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 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`.
@@ -418,11 +418,11 @@ 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::+[[def_remote_tracking_branch]]remote-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+ 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>>.
@@ -435,7 +435,7 @@ linux-nfs/master origin/master --------------------------------------------------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
@@ -41,7 +41,8 @@ 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-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
Now that the documentation is mostly consistant in the use of "remote
branch" Vs "remote-tracking branch", let's make this distinction explicit
early in the user-manual.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/user-manual.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
@@ -359,6 +359,11 @@ $ git branch -r origin/todo ------------------------------------------------+In this case, "origin" is called a remote repository, or "remote" for+short. The branches of this repository are called "remote branches"+from our point of view, and Git will maintain a copy of these+branches, called "remote-tracking branches" in the local repository.+ You cannot check out these remote-tracking branches, but you can examine them on a branch of your own, just as you would a tag:
@@ -1716,6 +1721,10 @@ one step: $ git pull origin master -------------------------------------------------+This command will fetch the changes from the remote branch to your+remote-tracking branch `origin/master`, and merge the result in the+current branch.+ 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 accomplish the above with just a simple
@@ -52,7 +52,7 @@ static struct option builtin_fetch_options[] = {OPT_SET_INT('n',NULL,&tags,"do not fetch all tags (--no-tags)",TAGS_UNSET),OPT_BOOLEAN('p',"prune",&prune,-"prune tracking branches no longer on remote"),+"prune remote-tracking branches no longer on remote"),OPT_BOOLEAN(0,"dry-run",&dry_run,"dry run"),OPT_BOOLEAN('k',"keep",&keep,"keep downloaded pack"),
@@ -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 machine into the master branch.
@@ -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 branches: ------------
@@ -128,8 +128,8 @@ Notes 'git gc' tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set-of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by 'git filter-branch' in+of branches and tags, but also objects referenced by the index,+remote-tracking branches, refs saved by 'git filter-branch' in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound).
@@ -402,8 +402,8 @@ could merge the changes into her master branch: alice$ git merge bob/master --------------------------------------This `merge` can also be done by 'pulling from her own remote-tracking branch', like this:+This `merge` can also be done by 'pulling from her own remote-tracking+branch', like this: ------------------------------------- alice$ git pull . remotes/bob/master
Older Gits talked about "updating" a file to add its content to the
index, but this terminology is confusing for new users. "to stage" is far
more intuitive and already used in e.g. the "git stage" command name.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/gittutorial-2.txt | 2 +-
t/t7508-status.sh | 34 +++++++++++++++++-----------------
wt-status.c | 2 +-
3 files changed, 19 insertions(+), 19 deletions(-)
@@ -373,7 +373,7 @@ $ git status # # new file: closing.txt #-# Changed but not updated:+# Changed but not staged for commit: # (use "git add <file>..." to update what will be committed) # # modified: file.txt
@@ -44,7 +44,7 @@ cat >expect <<\EOF## new file: dir2/added#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -73,7 +73,7 @@ cat >expect <<\EOF# Changes to be committed:# new file: dir2/added#-# Changed but not updated:+# Changed but not staged for commit:# modified: dir1/modified## Untracked files:
@@ -140,7 +140,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -167,7 +167,7 @@ cat >expect <<EOF# Changes to be committed:# new file: dir2/added#-# Changed but not updated:+# Changed but not staged for commit:# modified: dir1/modified## Untracked files not listed
@@ -202,7 +202,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -260,7 +260,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -320,7 +320,7 @@ cat >expect <<\EOF## new file: ../dir2/added#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -392,7 +392,7 @@ cat >expect <<\EOF## <GREEN>new file: dir2/added<RESET>#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -521,7 +521,7 @@ cat >expect <<\EOF## new file: dir2/added#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -614,7 +614,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -673,7 +673,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -718,7 +718,7 @@ test_expect_success 'status -s submodule summary' ' cat>expect<<EOF# On branch master-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -766,7 +766,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -819,7 +819,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -931,7 +931,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)# (commit or discard the untracked or modified content in submodules)
@@ -989,7 +989,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -1067,7 +1067,7 @@ test_expect_success ".git/config ignore=dirty doesn't suppress submodule summary cat>expect<<EOF# On branch master-# Changed but not updated:+# Changed but not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -88,7 +88,7 @@ static void wt_status_print_dirty_header(struct wt_status *s,{constchar*c=color(WT_STATUS_HEADER,s);-color_fprintf_ln(s->fp,c,"# Changed but not updated:");+color_fprintf_ln(s->fp,c,"# Changed but not staged for commit:");if(!advice_status_hints)return;if(!has_deleted)
"remote branch" is a branch hosted in a remote repository, while
"remote-tracking branch" is a copy of such branch, hosted locally.
The distinction is subtle when the copy is up-to-date, but rather
fundamental to understand what "git fetch" and "git push" do.
This patch should fix all incorrect usages in Documentation/ directory.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/config.txt | 7 ++++---
Documentation/git-branch.txt | 11 ++++++-----
Documentation/git-checkout.txt | 2 +-
Documentation/git-clone.txt | 2 +-
Documentation/git-describe.txt | 2 +-
Documentation/user-manual.txt | 9 +++++----
6 files changed, 18 insertions(+), 15 deletions(-)
@@ -601,8 +601,9 @@ branch.autosetupmerge:: this behavior can be chosen per-branch using the `--track` and `--no-track` options. The valid settings are: `false` -- no automatic setup is done; `true` -- automatic setup is done when the- starting point is a remote branch; `always` -- automatic setup is- done when the starting point is either a local branch or remote+ starting point is a remote-tracking branch; `always` --+ automatic setup is done when the starting point is either a+ local branch or remote-tracking branch. This option defaults to true. branch.autosetuprebase::
@@ -613,7 +614,7 @@ branch.autosetuprebase:: When `local`, rebase is set to true for tracked branches of other local branches. When `remote`, rebase is set to true for tracked branches of- remote branches.+ remote-tracking branches. When `always`, rebase will be set to true for all tracking branches. See "branch.autosetupmerge" for details on how to set up a
@@ -37,9 +37,9 @@ 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.
@@ -89,7 +89,8 @@ OPTIONS Move/rename a branch even if the new branch name already exists. --color[=<when>]::- Color branches to highlight current, local, and remote branches.+ Color branches to highlight current, local, and+ remote-tracking branches. The value must be always (the default), never, or auto. --no-color::
@@ -125,11 +126,11 @@ OPTIONS it directs `git pull` without arguments to pull from the upstream when the new branch is checked out. +-This behavior is the default when the start point is a remote branch.+This behavior is the default when the start point is a remote-tracking branch. Set the branch.autosetupmerge configuration variable to `false` if you want `git checkout` and `git branch` to always behave as if '--no-track' were given. Set it to `always` if you want this behavior when the-start-point is either a local or remote branch.+start-point is either a local or remote-tracking branch. --no-track:: Do not set up "upstream" configuration, even if the
@@ -98,7 +98,7 @@ entries; instead, unmerged entries are ignored. "--track" in linkgit:git-branch[1] for details. + If no '-b' option is given, the name of the new branch will be-derived from the remote branch. If "remotes/" or "refs/remotes/"+derived from the remote-tracking branch. If "remotes/" or "refs/remotes/" is prefixed it is stripped away, and then the part up to the next slash (which would be the nickname of the remote) is removed. This would tell us to use "hack" as the local branch when branching
@@ -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 target repository.
@@ -37,7 +37,7 @@ OPTIONS --all:: Instead of using only the annotated tags, use any ref found in `.git/refs/`. This option enables matching- any known branch, remote branch, or lightweight tag.+ any known branch, remote-tracking branch, or lightweight tag. --tags:: Instead of using only the annotated tags, use any tag
@@ -1724,7 +1724,8 @@ accomplish the above with just a simple $ git pull --------------------------------------------------More generally, a branch that is created from a remote branch will pull+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
@@ -2106,7 +2107,7 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git $ cd work --------------------------------------------------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 +2801,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
@@ -507,7 +507,7 @@ static int add_branch_for_removal(const char *refname,return0;}-/* don't delete non-remote refs */+/* don't delete non-remote-tracking refs */if(prefixcmp(refname,"refs/remotes")){/* advise user how to delete local branches */if(!prefixcmp(refname,"refs/heads/"))
@@ -791,9 +791,9 @@ static int rm(int argc, const char **argv)if(skipped.nr){fprintf(stderr,skipped.nr==1?-"Note: A non-remote branch was not removed; "+"Note: A non-remote-tracking branch was not removed; ""to delete it, use:\n":-"Note: Non-remote branches were not removed; "+"Note: Non-remote-tracking branches were not removed; ""to delete them, use:\n");for(i=0;i<skipped.nr;i++)fprintf(stderr," git branch -d %s\n",
"remote-tracking" branch makes it explicit that the branch is "tracking a
remote", as opposed to "remote, and tracking something".
See discussion in e.g.
http://mid.gmane.org/8835ADF9-45E5-4A26-9F7F-A72ECC065BB2@gmail.com
for more details.
This patch is a straightforward application of
perl -pi -e 's/remote tracking branch/remote-tracking branch/'
except in the RelNotes directory.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/config.txt | 2 +-
Documentation/fetch-options.txt | 2 +-
Documentation/git-log.txt | 2 +-
Documentation/git-pull.txt | 2 +-
Documentation/git-remote.txt | 4 ++--
Documentation/gittutorial.txt | 2 +-
Documentation/rev-list-options.txt | 2 +-
Documentation/user-manual.txt | 2 +-
builtin/checkout.c | 2 +-
t/t5513-fetch-track.sh | 2 +-
10 files changed, 11 insertions(+), 11 deletions(-)
@@ -708,7 +708,7 @@ color.diff.<slot>:: color.decorate.<slot>:: Use customized color for 'git log --decorate' output. `<slot>` is one of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local- branches, remote tracking branches, tags, stash and HEAD, respectively.+ branches, remote-tracking branches, tags, stash and HEAD, respectively. color.grep:: When set to `always`, always highlight matches. When `false` (or
@@ -36,7 +36,7 @@ ifndef::git-pull[] -p:: --prune::- After fetching, remove any remote tracking branches which+ After fetching, remove any remote-tracking branches which no longer exist on the remote. endif::git-pull[]
@@ -116,7 +116,7 @@ git log --follow builtin-rev-list.c:: git log --branches --not --remotes=origin:: Shows all commits that are in any of local branches but not in- any of remote tracking branches for 'origin' (what you have that+ any of remote-tracking branches for 'origin' (what you have that origin doesn't). git log master --not --remotes=*/master::
@@ -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.
@@ -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. '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'::
@@ -385,7 +385,7 @@ alice$ git fetch bob Unlike the longhand form, when Alice fetches from Bob using a remote repository shorthand set up with 'git remote', what was-fetched is stored in a remote tracking branch, in this case+fetched is stored in a remote-tracking branch, in this case `bob/master`. So after this: -------------------------------------
@@ -264,7 +264,7 @@ endif::git-rev-list[] Pretend as if all the refs in `refs/remotes` are listed on the command line as '<commit>'. If '<pattern>' is given, limit- remote tracking branches to ones matching given shell glob.+ remote-tracking branches to ones matching given shell glob. If pattern lacks '?', '*', or '[', '/*' at the end is implied. --glob=<glob-pattern>::
@@ -1700,7 +1700,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:
@@ -373,7 +373,7 @@ $ git status # # new file: closing.txt #-# Changed but not updated:+# Changed but not staged for commit: # (use "git add <file>..." to update what will be committed)
I find this even more confusing, though I admit that may be due to
habit more than anything else.
My reading, before:
These files were changed, but the version to be committed has
not been updated to include the latest changes (use "git add
<file>..." to add these changes to the index).
Afterwards:
These files were changed, but they are not staged for the
next commit.
If I do
echo hello >hi.c
git add hi.c
echo world >>hi.c
git status
then what does it mean to say "hi.c" is not staged for commit?
It actually does have changes ready for committing.
I would prefer to say something to the effect of
# Has unstaged changes:
Anyone wordsmiths out there with ideas to make this clearer?
@@ -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.
I find this scans better as "tracking branches", but consistent use of
jargon might trump that. Maybe it could be reworded somehow?
<2> clone sets these configuration variables by default.
They arrange for `git pull` to fetch and store the branches
of the mothership machine to local `remotes/origin/*` tracking
refs.
Not sure. remotes/origin/* are not branches for local development, so
calling them "branches" without a "remote-tracking" caveat can be
confusing.
@@ -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 branches:
The rest of the changes in this patch would have been caught by the
"perl -pi ..." command, except line wrapping got in the way. They are
obviously good.
@@ -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>>.
Why not keep the anchor name, like so:
<<def_tracking_branch,remote-tracking branch>>
(for brevity and to keep old links valid)?
@@ -373,7 +373,7 @@ $ git status # # new file: closing.txt #-# Changed but not updated:+# Changed but not staged for commit: # (use "git add <file>..." to update what will be committed)
I find this even more confusing, though I admit that may be due to
habit more than anything else.
Perhaps
# Changed but changes not staged for commit:
My reading, before:
These files were changed, but the version to be committed has
not been updated to include the latest changes (use "git add
<file>..." to add these changes to the index).
Afterwards:
These files were changed, but they are not staged for the
next commit.
If I do
echo hello >hi.c
git add hi.c
echo world >>hi.c
git status
then what does it mean to say "hi.c" is not staged for commit?
It actually does have changes ready for committing.
I would prefer to say something to the effect of
# Has unstaged changes:
Anyone wordsmiths out there with ideas to make this clearer?
But this might be a better solution.
--
Jakub Narebski
Poland
ShadeHawk on #git
Is this really more accurate? I thought what install_branch_config does
is to configure local branch "local" as downstream to remote branch
"remote" from origin "origin". That means:
- "git pull" fetches that remote and then merges the corresponding
remote-tracking branch
- "git remote show" compares the local branch to the remote branch
- "git branch -v" compares the local branch to the remote-tracking
branch
and so on.
For use by "git merge" and other "git fmt-merge-msg"-like consumers. Good.
quoted hunk
--- a/builtin/remote.c+++ b/builtin/remote.c
@@ -791,9 +791,9 @@ static int rm(int argc, const char **argv)if(skipped.nr){fprintf(stderr,skipped.nr==1?-"Note: A non-remote branch was not removed; "+"Note: A non-remote-tracking branch was not removed; ""to delete it, use:\n":-"Note: Non-remote branches were not removed; "+"Note: Non-remote-tracking branches were not removed; ""to delete them, use:\n");
This wording is ugly. Maybe something to this effect would be better?
Note: A ref outside the refs/remotes/ hierarchy was not removed:
@@ -1716,6 +1721,10 @@ one step: $ git pull origin master -------------------------------------------------+This command will fetch the changes from the remote branch to your+remote-tracking branch `origin/master`, and merge the result in the+current branch.+
I wish. :) Actually this fetched to FETCH_HEAD and left origin/master
alone the last time I checked.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:49:51
Jakub Narebski wrote:
Matthieu Moy [off-list ref] writes:
quoted
this is an attempt to be more consistant in the terminology used in Git.
Thank you very much for your work!
Yes, seconded!
I've sent comments as replies to patches 1, 2, 3, 4, 5, 7, 8, and 9.
Except as noted,
Reviewed-by: Jonathan Nieder <redacted>
These changes are not a moment too soon.
@@ -359,6 +359,11 @@ $ git branch -r origin/todo------------------------------------------------+In this case, "origin" is called a remote repository, or "remote" for+short. The branches of this repository are called "remote branches"+from our point of view, and Git will maintain a copy of these+branches, called "remote-tracking branches" in the local repository.
No. Git does not “maintain a copy of [the remote] branches”. It’s exactly one of the pitfalls I fell into: that Git, automagically, puts the *current* state of the remote branch into remote/branchname, or at least updates it behind my back whenever it gets the chance. The Pro Git book goes as far as saying “they’re moved automatically whenever you do any network communication,” which is extremely misleading. (And then it goes on: “Remote branches act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them.” This is a good way of saying it, except that “remote branches” should be ”remote-tracking branches,” and “connected to them” could be more concrete.)
I appreciate that this misunderstanding looks ridiculous in hindsight—it does to me, today. Luckily, I kept a copy of my old brain in thore/oldbrain and try to not fetch to it.
Also note that the two following lines in user-manual.txt are plain wrong (“You cannot check out these remote-tracking branches, but you can examine them on a branch of your own, just as you would a tag”).
I realise that it would be more constructive for me to suggest a concrete improvement, but I’m not quite there yet. I would really like to see a good conceptualisation, with strong, versatile verbs, of the relationships between bobsstuff bob/master and Bob’s master.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:49:52
Thore Husfeldt wrote:
On 23 Oct 2010, at 18:31, Matthieu Moy wrote:
quoted
+In this case, "origin" is called a remote repository, or "remote" for
+short. The branches of this repository are called "remote branches"
+from our point of view, and Git will maintain a copy of these
+branches, called "remote-tracking branches" in the local repository.
No. Git does not “maintain a copy of [the remote] branches”. It’s exactly one
of the pitfalls I fell into: that Git, automagically, puts the *current*
state of the remote branch into remote/branchname, or at least
[...]
I realise that it would be more constructive for me to suggest a concrete
improvement, but I’m not quite there yet.
Yes, it really would. Or could you try to figure out what exactly is
confusing in the wording (for example by giving an interpretation like
[do a good job at] maintain[ing] a copy of the branches
to indicate which part was confusing)?
As it is, I'm a little confused. At least according to one interpretation,
Git does maintain a copy of the remote branches. This is not tracking like
a Basset hound, and it is not maintaining a copy like cron running rsync
every 5 minutes, but git tracks remote branches like a human and
maintains a copy like a human running rsync whenever she finds time to
get around to it.
Of course, the wording can be improved. A nice side-effect of clear
suggestions intended to disambiguate one aspect is that they tend to
result in the text becoming clearer in other ways at the same time.
@@ -359,6 +359,11 @@ $ git branch -r origin/todo------------------------------------------------+In this case, "origin" is called a remote repository, or "remote" for+short. The branches of this repository are called "remote branches"+from our point of view, and Git will maintain a copy of these+branches, called "remote-tracking branches" in the local repository.
No. Git does not "maintain a copy of [the remote]
branches". Its exactly one of the pitfalls I fell into: that
Git, automagically, puts the *current* state of the remote branch
into remote/branchname, or at least updates it behind my back
whenever it gets the chance.
So you don't like the word "maintain" here, is it? Perhaps "keep"
instead of "maintain" would be a better word?
I guess that we can also add the following explanation:
Those "remote-tracking branches" would be updated to the state of tracked
branches in remote repository on fetch.
The Pro Git book goes as far as saying "theyre moved
automatically whenever you do any network communication," which
is extremely misleading. (And then it goes on: "Remote branches
act as bookmarks to remind you where the branches on your remote
repositories were the last time you connected to them." This is a
good way of saying it, except that "remote branches" should be
"remote-tracking branches,"
Right
and "connected to them" could be more concrete.)
I guess that the word 'connected' is used here to avoid repetition.
But it is a bit unprecise: "git remote show <remote>" connects to remote
repository but does not update remote-tracking branches.
Also note that the two following lines in user-manual.txt are plain
wrong ("You cannot check out these remote-tracking branches, but you
can examine them on a branch of your own, just as you would a tag").
This is simply outdated information, predating invention of detached
HEAD (also known as anonymous / unnamed branch). They are not _that_
wrong, as you don't checkout a remote-tracking branch: you checkout
_state_ of remote tracking branch, creating unnamed branch for that
(state marked in git-branch output as "(no branch)"). But I guess it
is too fine distinction (splitting hairs).
I realise that it would be more constructive for me to suggest a
concrete improvement, but Im not quite there yet. I would really
like to see a good conceptualisation, with strong, versatile verbs,
of the relationships between bobsstuff bob/master and Bobs master
Nevertheless your contributions, even those in the form of pointing
errors and inconsistences, are very welcome.
--
Jakub Narebski
Poland
ShadeHawk on #git
@@ -41,7 +41,8 @@ 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-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
Now that the documentation is mostly consistant in the use of "remote
branch" Vs "remote-tracking branch", let's make this distinction explicit
early in the user-manual.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/user-manual.txt | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
@@ -359,6 +359,14 @@ $ git branch -r origin/todo ------------------------------------------------+In this case, "origin" is called a remote repository, or "remote" for+short. The branches of this repository are called "remote branches"+from our point of view, and Git will keep a copy of these+branches, called "remote-tracking branches" in the local repository.+These remote-tracking branches are references that will be updated by+"git fetch" (hence by "git pull"). See+<<Updating-a-repository-With-git-fetch>> for details.+ You cannot check out these remote-tracking branches, but you can examine them on a branch of your own, just as you would a tag:
@@ -1716,14 +1724,19 @@ 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 -------------------------------------------------+This command will fetch the changes from the remote branches to your+remote-tracking branches `origin/*`, and merge default branch in 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
@@ -507,7 +507,7 @@ static int add_branch_for_removal(const char *refname,return0;}-/* don't delete non-remote refs */+/* don't delete non-remote-tracking refs */if(prefixcmp(refname,"refs/remotes")){/* advise user how to delete local branches */if(!prefixcmp(refname,"refs/heads/"))
@@ -791,9 +791,9 @@ static int rm(int argc, const char **argv)if(skipped.nr){fprintf(stderr,skipped.nr==1?-"Note: A non-remote branch was not removed; "+"Note: A branch outside the refs/remotes/ hierarchy was not removed;\n""to delete it, use:\n":-"Note: Non-remote branches were not removed; "+"Note: Some branches outside the refs/remotes/ hierarchy were not removed;\n""to delete them, use:\n");for(i=0;i<skipped.nr;i++)fprintf(stderr," git branch -d %s\n",
Older Gits talked about "updating" a file to add its content to the
index, but this terminology is confusing for new users. "to stage" is far
more intuitive and already used in e.g. the "git stage" command name.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/gittutorial-2.txt | 2 +-
t/t7508-status.sh | 34 +++++++++++++++++-----------------
wt-status.c | 2 +-
3 files changed, 19 insertions(+), 19 deletions(-)
@@ -373,7 +373,7 @@ $ git status # # new file: closing.txt #-# Changed but not updated:+# Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # # modified: file.txt
@@ -44,7 +44,7 @@ cat >expect <<\EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -73,7 +73,7 @@ cat >expect <<\EOF# Changes to be committed:# new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# modified: dir1/modified## Untracked files:
@@ -140,7 +140,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -167,7 +167,7 @@ cat >expect <<EOF# Changes to be committed:# new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# modified: dir1/modified## Untracked files not listed
@@ -202,7 +202,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -260,7 +260,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -320,7 +320,7 @@ cat >expect <<\EOF## new file: ../dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -392,7 +392,7 @@ cat >expect <<\EOF## <GREEN>new file: dir2/added<RESET>#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -521,7 +521,7 @@ cat >expect <<\EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -614,7 +614,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -673,7 +673,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -718,7 +718,7 @@ test_expect_success 'status -s submodule summary' ' cat>expect<<EOF# On branch master-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -766,7 +766,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -819,7 +819,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -931,7 +931,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)# (commit or discard the untracked or modified content in submodules)
@@ -989,7 +989,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -1067,7 +1067,7 @@ test_expect_success ".git/config ignore=dirty doesn't suppress submodule summary cat>expect<<EOF# On branch master-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -88,7 +88,7 @@ static void wt_status_print_dirty_header(struct wt_status *s,{constchar*c=color(WT_STATUS_HEADER,s);-color_fprintf_ln(s->fp,c,"# Changed but not updated:");+color_fprintf_ln(s->fp,c,"# Changes not staged for commit:");if(!advice_status_hints)return;if(!has_deleted)
@@ -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 machine into the master branch.
@@ -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 branches: ------------
@@ -128,8 +128,8 @@ Notes 'git gc' tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set-of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by 'git filter-branch' in+of branches and tags, but also objects referenced by the index,+remote-tracking branches, refs saved by 'git filter-branch' in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound).
@@ -402,8 +402,8 @@ could merge the changes into her master branch: alice$ git merge bob/master --------------------------------------This `merge` can also be done by 'pulling from her own remote-tracking branch', like this:+This `merge` can also be done by 'pulling from her own remote-tracking+branch', like this: ------------------------------------- alice$ git pull . remotes/bob/master
"remote branch" is a branch hosted in a remote repository, while
"remote-tracking branch" is a copy of such branch, hosted locally.
The distinction is subtle when the copy is up-to-date, but rather
fundamental to understand what "git fetch" and "git push" do.
This patch should fix all incorrect usages in Documentation/ directory.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/config.txt | 7 ++++---
Documentation/git-branch.txt | 11 ++++++-----
Documentation/git-checkout.txt | 2 +-
Documentation/git-clone.txt | 2 +-
Documentation/git-describe.txt | 2 +-
Documentation/user-manual.txt | 9 +++++----
6 files changed, 18 insertions(+), 15 deletions(-)
@@ -601,8 +601,9 @@ branch.autosetupmerge:: this behavior can be chosen per-branch using the `--track` and `--no-track` options. The valid settings are: `false` -- no automatic setup is done; `true` -- automatic setup is done when the- starting point is a remote branch; `always` -- automatic setup is- done when the starting point is either a local branch or remote+ starting point is a remote-tracking branch; `always` --+ automatic setup is done when the starting point is either a+ local branch or remote-tracking branch. This option defaults to true. branch.autosetuprebase::
@@ -613,7 +614,7 @@ branch.autosetuprebase:: When `local`, rebase is set to true for tracked branches of other local branches. When `remote`, rebase is set to true for tracked branches of- remote branches.+ remote-tracking branches. When `always`, rebase will be set to true for all tracking branches. See "branch.autosetupmerge" for details on how to set up a
@@ -37,9 +37,9 @@ 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.
@@ -89,7 +89,8 @@ OPTIONS Move/rename a branch even if the new branch name already exists. --color[=<when>]::- Color branches to highlight current, local, and remote branches.+ Color branches to highlight current, local, and+ remote-tracking branches. The value must be always (the default), never, or auto. --no-color::
@@ -125,11 +126,11 @@ OPTIONS it directs `git pull` without arguments to pull from the upstream when the new branch is checked out. +-This behavior is the default when the start point is a remote branch.+This behavior is the default when the start point is a remote-tracking branch. Set the branch.autosetupmerge configuration variable to `false` if you want `git checkout` and `git branch` to always behave as if '--no-track' were given. Set it to `always` if you want this behavior when the-start-point is either a local or remote branch.+start-point is either a local or remote-tracking branch. --no-track:: Do not set up "upstream" configuration, even if the
@@ -98,7 +98,7 @@ entries; instead, unmerged entries are ignored. "--track" in linkgit:git-branch[1] for details. + If no '-b' option is given, the name of the new branch will be-derived from the remote branch. If "remotes/" or "refs/remotes/"+derived from the remote-tracking branch. If "remotes/" or "refs/remotes/" is prefixed it is stripped away, and then the part up to the next slash (which would be the nickname of the remote) is removed. This would tell us to use "hack" as the local branch when branching
@@ -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 target repository.
@@ -37,7 +37,7 @@ OPTIONS --all:: Instead of using only the annotated tags, use any ref found in `.git/refs/`. This option enables matching- any known branch, remote branch, or lightweight tag.+ any known branch, remote-tracking branch, or lightweight tag. --tags:: Instead of using only the annotated tags, use any tag
@@ -1724,7 +1724,8 @@ accomplish the above with just a simple $ git pull --------------------------------------------------More generally, a branch that is created from a remote branch will pull+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
@@ -2106,7 +2107,7 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git $ cd work --------------------------------------------------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 +2801,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
@@ -680,7 +680,7 @@ color.branch:: color.branch.<slot>:: Use customized color for branch coloration. `<slot>` is one of `current` (the current branch), `local` (a local branch),- `remote` (a tracking branch in refs/remotes/), `plain` (other+ `remote` (a remote-tracking branch in refs/remotes/), `plain` (other refs). + The value for these configuration variables is a list of colors (at most
@@ -1102,7 +1102,7 @@ gui.newbranchtemplate:: linkgit:git-gui[1]. gui.pruneduringfetch::- "true" if linkgit:git-gui[1] should prune tracking branches when+ "true" if linkgit:git-gui[1] should prune remote-tracking branches when performing a fetch. The default value is "false". gui.trustmtime::
@@ -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
@@ -134,7 +134,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>`
@@ -147,9 +147,9 @@ refs/heads/*:refs/remotes/origin/* ------------ A globbing refspec must have a non-empty RHS (i.e. must store-what were fetched in tracking branches), and its LHS and RHS+what were fetched in remote-tracking branches), and its LHS and RHS must end with `/*`. The above specifies that all remote-branches are tracked using tracking branches in+branches are tracked using remote-tracking branches in `refs/remotes/origin/` hierarchy under the same name. The rule to determine which remote branch to merge after
@@ -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 "remotes/<name>".
@@ -177,7 +177,7 @@ On Automatic following ~~~~~~~~~~~~~~~~~~~~~~ If you are following somebody else's tree, you are most likely-using tracking branches (`refs/heads/origin` in traditional+using remote-tracking branches (`refs/heads/origin` in traditional layout, or `refs/remotes/origin/master` in the separate-remote layout). You usually want the tags from the other end.
@@ -232,7 +232,7 @@ this case. It may well be that among networking people, they may want to exchange the tags internal to their group, but in that workflow they are most likely tracking with each other's progress by-having tracking branches. Again, the heuristic to automatically+having remote-tracking branches. Again, the heuristic to automatically follow such tags is a good thing.
@@ -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 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`.
@@ -418,11 +418,11 @@ 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::+[[def_remote_tracking_branch]]remote-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+ 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>>.
@@ -435,7 +435,7 @@ linux-nfs/master origin/master --------------------------------------------------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
"remote-tracking" branch makes it explicit that the branch is "tracking a
remote", as opposed to "remote, and tracking something".
See discussion in e.g.
http://mid.gmane.org/8835ADF9-45E5-4A26-9F7F-A72ECC065BB2@gmail.com
for more details.
This patch is a straightforward application of
perl -pi -e 's/remote tracking branch/remote-tracking branch/'
except in the RelNotes directory.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/config.txt | 2 +-
Documentation/fetch-options.txt | 2 +-
Documentation/git-log.txt | 2 +-
Documentation/git-pull.txt | 2 +-
Documentation/git-remote.txt | 4 ++--
Documentation/gittutorial.txt | 2 +-
Documentation/rev-list-options.txt | 2 +-
Documentation/user-manual.txt | 2 +-
builtin/checkout.c | 2 +-
t/t5513-fetch-track.sh | 2 +-
10 files changed, 11 insertions(+), 11 deletions(-)
@@ -708,7 +708,7 @@ color.diff.<slot>:: color.decorate.<slot>:: Use customized color for 'git log --decorate' output. `<slot>` is one of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local- branches, remote tracking branches, tags, stash and HEAD, respectively.+ branches, remote-tracking branches, tags, stash and HEAD, respectively. color.grep:: When set to `always`, always highlight matches. When `false` (or
@@ -36,7 +36,7 @@ ifndef::git-pull[] -p:: --prune::- After fetching, remove any remote tracking branches which+ After fetching, remove any remote-tracking branches which no longer exist on the remote. endif::git-pull[]
@@ -116,7 +116,7 @@ git log --follow builtin-rev-list.c:: git log --branches --not --remotes=origin:: Shows all commits that are in any of local branches but not in- any of remote tracking branches for 'origin' (what you have that+ any of remote-tracking branches for 'origin' (what you have that origin doesn't). git log master --not --remotes=*/master::
@@ -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.
@@ -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. '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'::
@@ -385,7 +385,7 @@ alice$ git fetch bob Unlike the longhand form, when Alice fetches from Bob using a remote repository shorthand set up with 'git remote', what was-fetched is stored in a remote tracking branch, in this case+fetched is stored in a remote-tracking branch, in this case `bob/master`. So after this: -------------------------------------
@@ -264,7 +264,7 @@ endif::git-rev-list[] Pretend as if all the refs in `refs/remotes` are listed on the command line as '<commit>'. If '<pattern>' is given, limit- remote tracking branches to ones matching given shell glob.+ remote-tracking branches to ones matching given shell glob. If pattern lacks '?', '*', or '[', '/*' at the end is implied. --glob=<glob-pattern>::
@@ -1700,7 +1700,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:
@@ -52,7 +52,7 @@ static struct option builtin_fetch_options[] = {OPT_SET_INT('n',NULL,&tags,"do not fetch all tags (--no-tags)",TAGS_UNSET),OPT_BOOLEAN('p',"prune",&prune,-"prune tracking branches no longer on remote"),+"prune remote-tracking branches no longer on remote"),OPT_BOOLEAN(0,"dry-run",&dry_run,"dry run"),OPT_BOOLEAN('k',"keep",&keep,"keep downloaded pack"),
On Sat, 2010-10-23 at 18:31 +0200, Matthieu Moy wrote:
Following the discussion in
http://thread.gmane.org/gmane.comp.version-control.git/159287/http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=159288
this is an attempt to be more consistant in the terminology used in Git.
The first patch fixes git status's "changed but not updated", and the
rest tries to use "remote-tracking branch" consistantly. This
essentially changes the doc, and also does slight modifications to the
code. This changes error message, and maybe more controversially the
generated merge messages (in a separate patch in case this is too
controversial).
I've tried splitting this into systematic changes to ease review, but
patches should be applicable in any order (i.e. Junio: if you find
some of the patches good and uncontroversial, you can pick them
right away).
Patch "user-manual.txt: explain better the remote(-tracking) branch
terms" comes last, and adds a few sentences to make the distinction
between remote, remote branch, remote-tracking branches explicit.
Hopefully, this should avoid future users to have the same
difficulties as Thore ;-).
The last 2 patches are minor things I noticed while going through the
docs, but are essentially unrelated.
I'll be busy next week, so if anyone else wants to pick this patch
serie and update it according to list review, he's welcome. Otherwise,
it may have to wait.
Matthieu Moy (11):
Better "Changed but not updated" message in git-status
Remplace "remote tracking" with "remote-tracking"
Change remote tracking to remote-tracking in non-trivial places
Change "tracking branch" to "remote-tracking branch"
Change "tracking branch" to "remote-tracking branch" in C code
Change incorrect uses of "remote branch" meaning "remote-tracking"
Change incorrect "remote branch" to "remote tracking branch" in C
code
Use 'remote-tracking branch' in generated merge messages
user-manual.txt: explain better the remote(-tracking) branch terms
git-branch.txt: mention --set-upstream as a way to change upstream
configuration
git-http-push.txt: fix typo (branch -> branches)
I'm going to apply these to a branch of mine to see how they read in
context before I come to any definite conclusions. So far I like what I
see for the most part.
--
-Drew Northup N1XIM
AKA RvnPhnx on OPN
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
From: Jay Soffian <hidden> Date: 2016-06-15 22:49:52
On Mon, Oct 25, 2010 at 2:08 AM, Matthieu Moy [off-list ref] wrote:
You cannot check out these remote-tracking branches, but you can
examine them on a branch of your own, just as you would a tag:
Suggestion: "You do not commit directly to remote-tracking branches,
but you can examine them or create a branch from them, just as you
would a tag:"
j.
From: Jay Soffian <hidden> Date: 2016-06-15 22:49:52
On Mon, Oct 25, 2010 at 2:08 AM, Matthieu Moy [off-list ref] wrote:
+In this case, "origin" is called a remote repository, or "remote" for
+short. The branches of this repository are called "remote branches"
+from our point of view, and Git will keep a copy of these
+branches, called "remote-tracking branches" in the local repository.
+These remote-tracking branches are references that will be updated by
+"git fetch" (hence by "git pull"). See
+<<Updating-a-repository-With-git-fetch>> for details.
"...and Git will initially clone these branches into so-called
"remote-tracking branches" in the local repository. Thereafter, the
remote-tracking branches are updated upon fetching from[1] or pushing
to the remote. ([1] which also includes pulling.)
j.
"remote-tracking" branch makes it explicit that the branch is "tracking a
remote", as opposed to "remote, and tracking something".
See discussion in e.g.
http://mid.gmane.org/8835ADF9-45E5-4A26-9F7F-A72ECC065BB2@gmail.com
for more details.
This patch is a straightforward application of
perl -pi -e 's/remote tracking branch/remote-tracking branch/'
except in the RelNotes directory.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/config.txt | 2 +-
Documentation/fetch-options.txt | 2 +-
Documentation/git-log.txt | 2 +-
Documentation/git-pull.txt | 2 +-
Documentation/git-remote.txt | 4 ++--
Documentation/gittutorial.txt | 2 +-
Documentation/rev-list-options.txt | 2 +-
Documentation/user-manual.txt | 2 +-
builtin/checkout.c | 2 +-
t/t5513-fetch-track.sh | 2 +-
10 files changed, 11 insertions(+), 11 deletions(-)
@@ -708,7 +708,7 @@ color.diff.<slot>:: color.decorate.<slot>:: Use customized color for 'git log --decorate' output. `<slot>` is one of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local- branches, remote tracking branches, tags, stash and HEAD, respectively.+ branches, remote-tracking branches, tags, stash and HEAD, respectively. color.grep:: When set to `always`, always highlight matches. When `false` (or
@@ -36,7 +36,7 @@ ifndef::git-pull[] -p:: --prune::- After fetching, remove any remote tracking branches which+ After fetching, remove any remote-tracking branches which no longer exist on the remote. endif::git-pull[]
@@ -116,7 +116,7 @@ git log --follow builtin-rev-list.c:: git log --branches --not --remotes=origin:: Shows all commits that are in any of local branches but not in- any of remote tracking branches for 'origin' (what you have that+ any of remote-tracking branches for 'origin' (what you have that origin doesn't). git log master --not --remotes=*/master::
@@ -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.
@@ -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. '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'::
@@ -385,7 +385,7 @@ alice$ git fetch bob Unlike the longhand form, when Alice fetches from Bob using a remote repository shorthand set up with 'git remote', what was-fetched is stored in a remote tracking branch, in this case+fetched is stored in a remote-tracking branch, in this case `bob/master`. So after this: -------------------------------------
@@ -264,7 +264,7 @@ endif::git-rev-list[] Pretend as if all the refs in `refs/remotes` are listed on the command line as '<commit>'. If '<pattern>' is given, limit- remote tracking branches to ones matching given shell glob.+ remote-tracking branches to ones matching given shell glob. If pattern lacks '?', '*', or '[', '/*' at the end is implied. --glob=<glob-pattern>::
@@ -1700,7 +1700,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:
@@ -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 machine into the master branch.
@@ -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 branches: ------------
@@ -128,8 +128,8 @@ Notes 'git gc' tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set-of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by 'git filter-branch' in+of branches and tags, but also objects referenced by the index,+remote-tracking branches, refs saved by 'git filter-branch' in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound).
@@ -402,8 +402,8 @@ could merge the changes into her master branch: alice$ git merge bob/master --------------------------------------This `merge` can also be done by 'pulling from her own remote-tracking branch', like this:+This `merge` can also be done by 'pulling from her own remote-tracking+branch', like this: ------------------------------------- alice$ git pull . remotes/bob/master
@@ -507,7 +507,7 @@ static int add_branch_for_removal(const char *refname,return0;}-/* don't delete non-remote refs */+/* don't delete non-remote-tracking refs */if(prefixcmp(refname,"refs/remotes")){/* advise user how to delete local branches */if(!prefixcmp(refname,"refs/heads/"))
@@ -791,9 +791,9 @@ static int rm(int argc, const char **argv)if(skipped.nr){fprintf(stderr,skipped.nr==1?-"Note: A non-remote branch was not removed; "+"Note: A branch outside the refs/remotes/ hierarchy was not removed;\n""to delete it, use:\n":-"Note: Non-remote branches were not removed; "+"Note: Some branches outside the refs/remotes/ hierarchy were not removed;\n""to delete them, use:\n");for(i=0;i<skipped.nr;i++)fprintf(stderr," git branch -d %s\n",
"remote branch" is a branch hosted in a remote repository, while
"remote-tracking branch" is a copy of such branch, hosted locally.
The distinction is subtle when the copy is up-to-date, but rather
fundamental to understand what "git fetch" and "git push" do.
This patch should fix all incorrect usages in Documentation/ directory.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/config.txt | 7 ++++---
Documentation/git-branch.txt | 11 ++++++-----
Documentation/git-checkout.txt | 2 +-
Documentation/git-clone.txt | 2 +-
Documentation/git-describe.txt | 2 +-
Documentation/user-manual.txt | 9 +++++----
6 files changed, 18 insertions(+), 15 deletions(-)
@@ -601,8 +601,9 @@ branch.autosetupmerge:: this behavior can be chosen per-branch using the `--track` and `--no-track` options. The valid settings are: `false` -- no automatic setup is done; `true` -- automatic setup is done when the- starting point is a remote branch; `always` -- automatic setup is- done when the starting point is either a local branch or remote+ starting point is a remote-tracking branch; `always` --+ automatic setup is done when the starting point is either a+ local branch or remote-tracking branch. This option defaults to true. branch.autosetuprebase::
@@ -613,7 +614,7 @@ branch.autosetuprebase:: When `local`, rebase is set to true for tracked branches of other local branches. When `remote`, rebase is set to true for tracked branches of- remote branches.+ remote-tracking branches. When `always`, rebase will be set to true for all tracking branches. See "branch.autosetupmerge" for details on how to set up a
@@ -37,9 +37,9 @@ 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.
@@ -89,7 +89,8 @@ OPTIONS Move/rename a branch even if the new branch name already exists. --color[=<when>]::- Color branches to highlight current, local, and remote branches.+ Color branches to highlight current, local, and+ remote-tracking branches. The value must be always (the default), never, or auto. --no-color::
@@ -125,11 +126,11 @@ OPTIONS it directs `git pull` without arguments to pull from the upstream when the new branch is checked out. +-This behavior is the default when the start point is a remote branch.+This behavior is the default when the start point is a remote-tracking branch. Set the branch.autosetupmerge configuration variable to `false` if you want `git checkout` and `git branch` to always behave as if '--no-track' were given. Set it to `always` if you want this behavior when the-start-point is either a local or remote branch.+start-point is either a local or remote-tracking branch. --no-track:: Do not set up "upstream" configuration, even if the
@@ -98,7 +98,7 @@ entries; instead, unmerged entries are ignored. "--track" in linkgit:git-branch[1] for details. + If no '-b' option is given, the name of the new branch will be-derived from the remote branch. If "remotes/" or "refs/remotes/"+derived from the remote-tracking branch. If "remotes/" or "refs/remotes/" is prefixed it is stripped away, and then the part up to the next slash (which would be the nickname of the remote) is removed. This would tell us to use "hack" as the local branch when branching
@@ -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 target repository.
@@ -37,7 +37,7 @@ OPTIONS --all:: Instead of using only the annotated tags, use any ref found in `.git/refs/`. This option enables matching- any known branch, remote branch, or lightweight tag.+ any known branch, remote-tracking branch, or lightweight tag. --tags:: Instead of using only the annotated tags, use any tag
@@ -1724,7 +1724,8 @@ accomplish the above with just a simple $ git pull --------------------------------------------------More generally, a branch that is created from a remote branch will pull+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
@@ -2106,7 +2107,7 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git $ cd work --------------------------------------------------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 +2801,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
@@ -368,13 +368,16 @@ They are references that will be updated by "git fetch" (hence by "git pull"), and by "git push". See <<Updating-a-repository-With-git-fetch>> for details.-You cannot check out these remote-tracking branches, but you can-examine them on a branch of your own, just as you would a tag:+You might want to build on one of these remote-tracking branches+on a branch of your own, just as you would for a tag: ------------------------------------------------ $ git checkout -b my-todo-copy origin/todo ------------------------------------------------+You can also check out "origin/todo" directly to examine it or+write a one-off patch. See <<detached-head,detached head>>.+ Note that the name "origin" is just the name that git uses by default to refer to the repository that you cloned from.
@@ -41,7 +41,8 @@ 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-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
Now that the documentation is mostly consistant in the use of "remote
branch" Vs "remote-tracking branch", let's make this distinction explicit
early in the user-manual.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/user-manual.txt | 20 +++++++++++++++++---
1 files changed, 17 insertions(+), 3 deletions(-)
@@ -344,7 +344,8 @@ Examining branches from a remote repository The "master" branch that was created at the time you cloned is a copy of the HEAD in the repository that you cloned from. That repository may also have had other branches, though, and your local repository-keeps branches which track each of those remote branches, which you+keeps branches which track each of those remote branches, called+remote-tracking branches, which you can view using the "-r" option to linkgit:git-branch[1]: ------------------------------------------------
@@ -359,6 +360,14 @@ $ git branch -r origin/todo ------------------------------------------------+In this case, "origin" is called a remote repository, or "remote" for+short. The branches of this repository are called "remote branches"+from our point of view. The remote-tracking branches are created in+the local repository at clone time, as a copy of the remote branches.+They are references that will be updated by "git fetch" (hence by "git+pull"), and by "git push". See+<<Updating-a-repository-With-git-fetch>> for details.+ You cannot check out these remote-tracking branches, but you can examine them on a branch of your own, just as you would a tag:
@@ -1716,14 +1725,19 @@ 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 -------------------------------------------------+This command will fetch the changes from the remote branches to your+remote-tracking branches `origin/*`, and merge default branch in 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
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 <redacted>
---
Documentation/config.txt | 4 ++--
Documentation/git-fetch.txt | 2 +-
Documentation/git-pull.txt | 6 +++---
Documentation/git-remote.txt | 2 +-
Documentation/git-tag.txt | 4 ++--
Documentation/glossary-content.txt | 20 ++++++++++----------
Documentation/user-manual.txt | 2 +-
builtin/checkout.c | 2 +-
builtin/fetch.c | 4 ++--
remote.c | 2 +-
10 files changed, 24 insertions(+), 24 deletions(-)
@@ -680,7 +680,7 @@ color.branch:: color.branch.<slot>:: Use customized color for branch coloration. `<slot>` is one of `current` (the current branch), `local` (a local branch),- `remote` (a tracking branch in refs/remotes/), `plain` (other+ `remote` (a remote-tracking branch in refs/remotes/), `plain` (other refs). + The value for these configuration variables is a list of colors (at most
@@ -1102,7 +1102,7 @@ gui.newbranchtemplate:: linkgit:git-gui[1]. gui.pruneduringfetch::- "true" if linkgit:git-gui[1] should prune tracking branches when+ "true" if linkgit:git-gui[1] should prune remote-tracking branches when performing a fetch. The default value is "false". gui.trustmtime::
@@ -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
@@ -134,7 +134,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>`
@@ -147,9 +147,9 @@ refs/heads/*:refs/remotes/origin/* ------------ A globbing refspec must have a non-empty RHS (i.e. must store-what were fetched in tracking branches), and its LHS and RHS+what were fetched in remote-tracking branches), and its LHS and RHS must end with `/*`. The above specifies that all remote-branches are tracked using tracking branches in+branches are tracked using remote-tracking branches in `refs/remotes/origin/` hierarchy under the same name. The rule to determine which remote branch to merge after
@@ -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 "remotes/<name>".
@@ -177,7 +177,7 @@ On Automatic following ~~~~~~~~~~~~~~~~~~~~~~ If you are following somebody else's tree, you are most likely-using tracking branches (`refs/heads/origin` in traditional+using remote-tracking branches (`refs/heads/origin` in traditional layout, or `refs/remotes/origin/master` in the separate-remote layout). You usually want the tags from the other end.
@@ -232,7 +232,7 @@ this case. It may well be that among networking people, they may want to exchange the tags internal to their group, but in that workflow they are most likely tracking with each other's progress by-having tracking branches. Again, the heuristic to automatically+having remote-tracking branches. Again, the heuristic to automatically follow such tags is a good thing.
@@ -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 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 master branch head as to-upstream branch at $URL". See also linkgit:git-push[1].+[[def_remote_tracking_branch]]remote-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 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 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
@@ -435,7 +435,7 @@ linux-nfs/master origin/master --------------------------------------------------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
@@ -52,7 +52,7 @@ static struct option builtin_fetch_options[] = {OPT_SET_INT('n',NULL,&tags,"do not fetch all tags (--no-tags)",TAGS_UNSET),OPT_BOOLEAN('p',"prune",&prune,-"prune tracking branches no longer on remote"),+"prune remote-tracking branches no longer on remote"),OPT_BOOLEAN(0,"dry-run",&dry_run,"dry run"),OPT_BOOLEAN('k',"keep",&keep,"keep downloaded pack"),
Older Gits talked about "updating" a file to add its content to the
index, but this terminology is confusing for new users. "to stage" is far
more intuitive and already used in e.g. the "git stage" command name.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/gittutorial-2.txt | 2 +-
t/t7508-status.sh | 34 +++++++++++++++++-----------------
wt-status.c | 2 +-
3 files changed, 19 insertions(+), 19 deletions(-)
@@ -373,7 +373,7 @@ $ git status # # new file: closing.txt #-# Changed but not updated:+# Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # # modified: file.txt
@@ -44,7 +44,7 @@ cat >expect <<\EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -73,7 +73,7 @@ cat >expect <<\EOF# Changes to be committed:# new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# modified: dir1/modified## Untracked files:
@@ -140,7 +140,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -167,7 +167,7 @@ cat >expect <<EOF# Changes to be committed:# new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# modified: dir1/modified## Untracked files not listed
@@ -202,7 +202,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -260,7 +260,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -320,7 +320,7 @@ cat >expect <<\EOF## new file: ../dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -392,7 +392,7 @@ cat >expect <<\EOF## <GREEN>new file: dir2/added<RESET>#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -521,7 +521,7 @@ cat >expect <<\EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -614,7 +614,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -673,7 +673,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -718,7 +718,7 @@ test_expect_success 'status -s submodule summary' ' cat>expect<<EOF# On branch master-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -766,7 +766,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -819,7 +819,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -931,7 +931,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)# (commit or discard the untracked or modified content in submodules)
@@ -989,7 +989,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -1067,7 +1067,7 @@ test_expect_success ".git/config ignore=dirty doesn't suppress submodule summary cat>expect<<EOF# On branch master-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -88,7 +88,7 @@ static void wt_status_print_dirty_header(struct wt_status *s,{constchar*c=color(WT_STATUS_HEADER,s);-color_fprintf_ln(s->fp,c,"# Changed but not updated:");+color_fprintf_ln(s->fp,c,"# Changes not staged for commit:");if(!advice_status_hints)return;if(!has_deleted)
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:49:55
Matthieu Moy wrote:
quoted hunk
+++ b/wt-status.c
@@ -88,7 +88,7 @@ static void wt_status_print_dirty_header(struct wt_status *s,{constchar*c=color(WT_STATUS_HEADER,s);-color_fprintf_ln(s->fp,c,"# Changed but not updated:");+color_fprintf_ln(s->fp,c,"# Changes not staged for commit:");if(!advice_status_hints)return;
Result looks like:
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: foo.c
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: foo.c
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# bar.c
which is both clearer and more consistent. So for what it's worth,
Acked-by: Jonathan Nieder <redacted>
@@ -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 machine into the master branch.
Just for the record: I still don't think this hunk fits with the rest
of the patch, and I think it just switches from one bad wording to
another.
This is the "Everyday git" document, one of the first pages a new user
might read. Using jargon that does not explain itself (whether it is
"tracking branches" or "remote-tracking branches") is not really a
good idea.
Wouldn't it be possible to split this into a separate patch, so it
does not hold back the other "add hyphen" changes?
This still seems inaccurate (and even misleading). Presumably you mean
... to merge remote-tracking branch "origin/remote"
based on origin "origin".
or
... to merge remote branch "remote"
taken from origin "origin"
or even better,
Configure local branch "local" as downstream to branch "remote"
from remote "origin". Used by git branch --set-upstream.
More confusion could presumably be avoided by renaming the parameters.
I didn't follow before --- what concrete effect does this have? Are
scripts affected? Is fmt-merge-msg affected?
quoted hunk
--- a/builtin/remote.c+++ b/builtin/remote.c
@@ -791,9 +791,9 @@ static int rm(int argc, const char **argv)if(skipped.nr){fprintf(stderr,skipped.nr==1?-"Note: A non-remote branch was not removed; "+"Note: A branch outside the refs/remotes/ hierarchy was not removed;\n""to delete it, use:\n":-"Note: Non-remote branches were not removed; "+"Note: Some branches outside the refs/remotes/ hierarchy were not removed;\n""to delete them, use:\n");for(i=0;i<skipped.nr;i++)fprintf(stderr," git branch -d %s\n",
Nice.
Maybe the commit message should explain the reasoning, something like:
The non-deleted branch is somehow remote-tracking since "fetch" feeds
it, and the code detecting this case is:
/* don't delete non-remote-tracking refs */
if (prefixcmp(refname, "refs/remotes")) {
/* advise user how to delete local branches */
if (!prefixcmp(refname, "refs/heads/"))
string_list_append(branches->skipped,
abbrev_branch(refname));
/* silently skip over other non-remote refs */
return 0;
}
hence, really "branches outside the refs/remotes/ hierarchy".
Thanks for your tireless work. Everything not mentioned above looks good.
@@ -341,30 +342,38 @@ $ git branch -r Examining branches from a remote repository ------------------------------------------- The "master" branch that was created at the time you cloned is a copy of the HEAD in the repository that you cloned from. That repository may also have had other branches, though, and your local repository keeps branches which track each of those remote branches, which you can view using the "-r" option to linkgit:git-branch[1]: ------------------------------------------------ $ git branch -r origin/HEAD origin/html origin/maint origin/man origin/master origin/next origin/pu origin/todo ------------------------------------------------+In this case, "origin" is called a remote repository, or "remote" for+short.
"In this case" seems redundant (since we did not explain what other
case it is being opposed to). "origin" has not been explained yet.
Maybe something along these lines (sorry for my poor wording)
The repository of origin is called a remote repository, or a "remote" for
short.
would improve it?
The branches of this repository are called "remote branches"
+from our point of view. The remote-tracking branches are created in
+the local repository at clone time, as a copy of the remote branches.
Sentence structure. Maybe
The branches of this repository are called "remote branches"
from our point of view. The remote-tracking branches listed above
were created based on the remote branches at clone time and will be
updated by "git fetch" and "git push".
See <<Updating -a-repository-With-git-fetch>> for details.
quoted hunk
+They are references that will be updated by "git fetch" (hence by "git
+pull"), and by "git push". See
+<<Updating-a-repository-With-git-fetch>> for details.
+
You cannot check out these remote-tracking branches, but you can
examine them on a branch of your own, just as you would a tag:
------------------------------------------------
$ git checkout -b my-todo-copy origin/todo
------------------------------------------------
Note that the name "origin" is just the name that git uses by default
to refer to the repository that you cloned from.
@@ -1716,14 +1725,19 @@ one step:
[...]
-------------------------------------------------
$ git pull
-------------------------------------------------
+This command will fetch the changes from the remote branches to your
+remote-tracking branches `origin/*`, and merge default branch in the
+current branch.
+
Article use. Probably something like
s/the changes/changes/
s/merge default branch in/merge the default branch into/
would do.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:49:55
Matthieu Moy wrote:
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.
For what it's worth:
Reviewed-by: Jonathan Nieder <redacted>
@@ -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 linkgit:git-push[1].+[[def_remote_tracking_branch]]remote-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 remote-tracking branch can usually be+ identified as the right-hand-side <<def_ref,ref>> in a Pull:+ <<def_refspec,refspec>>.+ [[def_repository]]repository::
In particular, your explanation for this hunk makes sense. Any links
out in the world to "gitglossary.html#def_tracking_branch" would go to
the top of the page after this change. Once there, the reader can
easily search for "tracking branch" to find the right entry.
Older Gits talked about "updating" a file to add its content to the
index, but this terminology is confusing for new users. "to stage" is far
more intuitive and already used in e.g. the "git stage" command name.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/gittutorial-2.txt | 2 +-
t/t7508-status.sh | 34 +++++++++++++++++-----------------
wt-status.c | 2 +-
3 files changed, 19 insertions(+), 19 deletions(-)
@@ -373,7 +373,7 @@ $ git status # # new file: closing.txt #-# Changed but not updated:+# Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # # modified: file.txt
@@ -44,7 +44,7 @@ cat >expect <<\EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -73,7 +73,7 @@ cat >expect <<\EOF# Changes to be committed:# new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# modified: dir1/modified## Untracked files:
@@ -140,7 +140,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -167,7 +167,7 @@ cat >expect <<EOF# Changes to be committed:# new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# modified: dir1/modified## Untracked files not listed
@@ -202,7 +202,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -260,7 +260,7 @@ cat >expect <<EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -320,7 +320,7 @@ cat >expect <<\EOF## new file: ../dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -392,7 +392,7 @@ cat >expect <<\EOF## <GREEN>new file: dir2/added<RESET>#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -521,7 +521,7 @@ cat >expect <<\EOF## new file: dir2/added#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -614,7 +614,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -673,7 +673,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -718,7 +718,7 @@ test_expect_success 'status -s submodule summary' ' cat>expect<<EOF# On branch master-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -766,7 +766,7 @@ cat >expect <<EOF# new file: dir2/added# new file: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -819,7 +819,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -931,7 +931,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)# (commit or discard the untracked or modified content in submodules)
@@ -989,7 +989,7 @@ cat > expect << EOF## modified: sm#-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -1067,7 +1067,7 @@ test_expect_success ".git/config ignore=dirty doesn't suppress submodule summary cat>expect<<EOF# On branch master-# Changed but not updated:+# Changes not staged for commit:# (use "git add <file>..." to update what will be committed)# (use "git checkout -- <file>..." to discard changes in working directory)#
@@ -88,7 +88,7 @@ static void wt_status_print_dirty_header(struct wt_status *s,{constchar*c=color(WT_STATUS_HEADER,s);-color_fprintf_ln(s->fp,c,"# Changed but not updated:");+color_fprintf_ln(s->fp,c,"# Changes not staged for commit:");if(!advice_status_hints)return;if(!has_deleted)
"remote-tracking" branch makes it explicit that the branch is "tracking a
remote", as opposed to "remote, and tracking something".
See discussion in e.g.
http://mid.gmane.org/8835ADF9-45E5-4A26-9F7F-A72ECC065BB2@gmail.com
for more details.
This patch is a straightforward application of
perl -pi -e 's/remote tracking branch/remote-tracking branch/'
except in the RelNotes directory.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/config.txt | 2 +-
Documentation/fetch-options.txt | 2 +-
Documentation/git-log.txt | 2 +-
Documentation/git-pull.txt | 2 +-
Documentation/git-remote.txt | 4 ++--
Documentation/gittutorial.txt | 2 +-
Documentation/rev-list-options.txt | 2 +-
Documentation/user-manual.txt | 2 +-
builtin/checkout.c | 2 +-
t/t5513-fetch-track.sh | 2 +-
10 files changed, 11 insertions(+), 11 deletions(-)
@@ -708,7 +708,7 @@ color.diff.<slot>:: color.decorate.<slot>:: Use customized color for 'git log --decorate' output. `<slot>` is one of `branch`, `remoteBranch`, `tag`, `stash` or `HEAD` for local- branches, remote tracking branches, tags, stash and HEAD, respectively.+ branches, remote-tracking branches, tags, stash and HEAD, respectively. color.grep:: When set to `always`, always highlight matches. When `false` (or
@@ -36,7 +36,7 @@ ifndef::git-pull[] -p:: --prune::- After fetching, remove any remote tracking branches which+ After fetching, remove any remote-tracking branches which no longer exist on the remote. endif::git-pull[]
@@ -116,7 +116,7 @@ git log --follow builtin-rev-list.c:: git log --branches --not --remotes=origin:: Shows all commits that are in any of local branches but not in- any of remote tracking branches for 'origin' (what you have that+ any of remote-tracking branches for 'origin' (what you have that origin doesn't). git log master --not --remotes=*/master::
@@ -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.
@@ -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. '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'::
@@ -385,7 +385,7 @@ alice$ git fetch bob Unlike the longhand form, when Alice fetches from Bob using a remote repository shorthand set up with 'git remote', what was-fetched is stored in a remote tracking branch, in this case+fetched is stored in a remote-tracking branch, in this case `bob/master`. So after this: -------------------------------------
@@ -264,7 +264,7 @@ endif::git-rev-list[] Pretend as if all the refs in `refs/remotes` are listed on the command line as '<commit>'. If '<pattern>' is given, limit- remote tracking branches to ones matching given shell glob.+ remote-tracking branches to ones matching given shell glob. If pattern lacks '?', '*', or '[', '/*' at the end is implied. --glob=<glob-pattern>::
@@ -1700,7 +1700,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:
@@ -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 branches: ------------
@@ -128,8 +128,8 @@ Notes 'git gc' tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set-of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by 'git filter-branch' in+of branches and tags, but also objects referenced by the index,+remote-tracking branches, refs saved by 'git filter-branch' in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound).
@@ -402,8 +402,8 @@ could merge the changes into her master branch: alice$ git merge bob/master --------------------------------------This `merge` can also be done by 'pulling from her own remote-tracking branch', like this:+This `merge` can also be done by 'pulling from her own remote-tracking+branch', like this: ------------------------------------- alice$ git pull . remotes/bob/master
@@ -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 machine into the master branch.
"remote branch" is a branch hosted in a remote repository, while
"remote-tracking branch" is a copy of such branch, hosted locally.
The distinction is subtle when the copy is up-to-date, but rather
fundamental to understand what "git fetch" and "git push" do.
This patch should fix all incorrect usages in Documentation/ directory.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/config.txt | 7 ++++---
Documentation/git-branch.txt | 11 ++++++-----
Documentation/git-checkout.txt | 2 +-
Documentation/git-clone.txt | 2 +-
Documentation/git-describe.txt | 2 +-
Documentation/user-manual.txt | 9 +++++----
6 files changed, 18 insertions(+), 15 deletions(-)
@@ -601,8 +601,9 @@ branch.autosetupmerge:: this behavior can be chosen per-branch using the `--track` and `--no-track` options. The valid settings are: `false` -- no automatic setup is done; `true` -- automatic setup is done when the- starting point is a remote branch; `always` -- automatic setup is- done when the starting point is either a local branch or remote+ starting point is a remote-tracking branch; `always` --+ automatic setup is done when the starting point is either a+ local branch or remote-tracking branch. This option defaults to true. branch.autosetuprebase::
@@ -613,7 +614,7 @@ branch.autosetuprebase:: When `local`, rebase is set to true for tracked branches of other local branches. When `remote`, rebase is set to true for tracked branches of- remote branches.+ remote-tracking branches. When `always`, rebase will be set to true for all tracking branches. See "branch.autosetupmerge" for details on how to set up a
@@ -37,9 +37,9 @@ 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.
@@ -89,7 +89,8 @@ OPTIONS Move/rename a branch even if the new branch name already exists. --color[=<when>]::- Color branches to highlight current, local, and remote branches.+ Color branches to highlight current, local, and+ remote-tracking branches. The value must be always (the default), never, or auto. --no-color::
@@ -125,11 +126,11 @@ OPTIONS it directs `git pull` without arguments to pull from the upstream when the new branch is checked out. +-This behavior is the default when the start point is a remote branch.+This behavior is the default when the start point is a remote-tracking branch. Set the branch.autosetupmerge configuration variable to `false` if you want `git checkout` and `git branch` to always behave as if '--no-track' were given. Set it to `always` if you want this behavior when the-start-point is either a local or remote branch.+start-point is either a local or remote-tracking branch. --no-track:: Do not set up "upstream" configuration, even if the
@@ -98,7 +98,7 @@ entries; instead, unmerged entries are ignored. "--track" in linkgit:git-branch[1] for details. + If no '-b' option is given, the name of the new branch will be-derived from the remote branch. If "remotes/" or "refs/remotes/"+derived from the remote-tracking branch. If "remotes/" or "refs/remotes/" is prefixed it is stripped away, and then the part up to the next slash (which would be the nickname of the remote) is removed. This would tell us to use "hack" as the local branch when branching
@@ -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 target repository.
@@ -37,7 +37,7 @@ OPTIONS --all:: Instead of using only the annotated tags, use any ref found in `.git/refs/`. This option enables matching- any known branch, remote branch, or lightweight tag.+ any known branch, remote-tracking branch, or lightweight tag. --tags:: Instead of using only the annotated tags, use any tag
@@ -1724,7 +1724,8 @@ accomplish the above with just a simple $ git pull --------------------------------------------------More generally, a branch that is created from a remote branch will pull+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
@@ -2106,7 +2107,7 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git $ cd work --------------------------------------------------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 +2801,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
@@ -41,7 +41,8 @@ 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-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
(Just like we did for documentation already)
In the process, we change "non-remote branch" to "branch outside the
refs/remotes/ hierarchy" to avoid the ugly "non-remote-tracking branch".
The new formulation actually corresponds to how the code detects this
case (i.e. prefixcmp(refname, "refs/remotes")).
Signed-off-by: Matthieu Moy <redacted>
---
branch.h | 4 ++--
builtin/fetch.c | 2 +-
builtin/remote.c | 6 +++---
contrib/examples/builtin-fetch--tool.c | 2 +-
t/t5505-remote.sh | 8 +++++---
t/t7608-merge-messages.sh | 2 +-
6 files changed, 13 insertions(+), 11 deletions(-)
@@ -507,7 +507,7 @@ static int add_branch_for_removal(const char *refname,return0;}-/* don't delete non-remote refs */+/* don't delete non-remote-tracking refs */if(prefixcmp(refname,"refs/remotes")){/* advise user how to delete local branches */if(!prefixcmp(refname,"refs/heads/"))
@@ -791,9 +791,9 @@ static int rm(int argc, const char **argv)if(skipped.nr){fprintf(stderr,skipped.nr==1?-"Note: A non-remote branch was not removed; "+"Note: A branch outside the refs/remotes/ hierarchy was not removed;\n""to delete it, use:\n":-"Note: Non-remote branches were not removed; "+"Note: Some branches outside the refs/remotes/ hierarchy were not removed;\n""to delete them, use:\n");for(i=0;i<skipped.nr;i++)fprintf(stderr," git branch -d %s\n",
@@ -360,21 +360,23 @@ $ git branch -r origin/todo -------------------------------------------------In this case, "origin" is called a remote repository, or "remote" for-short. The branches of this repository are called "remote branches"-from our point of view. The remote-tracking branches are created in-the local repository at clone time, as a copy of the remote branches.-They are references that will be updated by "git fetch" (hence by "git-pull"), and by "git push". See-<<Updating-a-repository-With-git-fetch>> for details.+In this example, "origin" is called a remote repository, or "remote"+for short. The branches of this repository are called "remote+branches" from our point of view. The remote-tracking branches listed+above were created based on the remote branches at clone time and will+be updated by "git fetch" (hence "git pull) and "git push". See+<<Updating -a-repository-With-git-fetch>> for details.-You cannot check out these remote-tracking branches, but you can-examine them on a branch of your own, just as you would a tag:+You might want to build on one of these remote-tracking branches+on a branch of your own, just as you would for a tag: ------------------------------------------------ $ git checkout -b my-todo-copy origin/todo ------------------------------------------------+You can also check out "origin/todo" directly to examine it or+write a one-off patch. See <<detached-head,detached head>>.+ Note that the name "origin" is just the name that git uses by default to refer to the repository that you cloned from.
@@ -1734,9 +1736,9 @@ accomplish the above with just a simple $ git pull --------------------------------------------------This command will fetch the changes from the remote branches to your-remote-tracking branches `origin/*`, and merge default branch in the-current branch.+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
Now that the documentation is mostly consistant in the use of "remote
branch" Vs "remote-tracking branch", let's make this distinction explicit
early in the user-manual.
Signed-off-by: Matthieu Moy <redacted>
---
Documentation/user-manual.txt | 20 +++++++++++++++++---
1 files changed, 17 insertions(+), 3 deletions(-)
@@ -344,7 +344,8 @@ Examining branches from a remote repository The "master" branch that was created at the time you cloned is a copy of the HEAD in the repository that you cloned from. That repository may also have had other branches, though, and your local repository-keeps branches which track each of those remote branches, which you+keeps branches which track each of those remote branches, called+remote-tracking branches, which you can view using the "-r" option to linkgit:git-branch[1]: ------------------------------------------------
@@ -359,6 +360,14 @@ $ git branch -r origin/todo ------------------------------------------------+In this case, "origin" is called a remote repository, or "remote" for+short. The branches of this repository are called "remote branches"+from our point of view. The remote-tracking branches are created in+the local repository at clone time, as a copy of the remote branches.+They are references that will be updated by "git fetch" (hence by "git+pull"), and by "git push". See+<<Updating-a-repository-With-git-fetch>> for details.+ You cannot check out these remote-tracking branches, but you can examine them on a branch of your own, just as you would a tag:
@@ -1716,14 +1725,19 @@ 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 -------------------------------------------------+This command will fetch the changes from the remote branches to your+remote-tracking branches `origin/*`, and merge default branch in 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
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 <redacted>
---
Documentation/config.txt | 4 ++--
Documentation/git-fetch.txt | 2 +-
Documentation/git-pull.txt | 6 +++---
Documentation/git-remote.txt | 2 +-
Documentation/git-tag.txt | 4 ++--
Documentation/glossary-content.txt | 20 ++++++++++----------
Documentation/user-manual.txt | 2 +-
builtin/checkout.c | 2 +-
builtin/fetch.c | 4 ++--
remote.c | 2 +-
10 files changed, 24 insertions(+), 24 deletions(-)
@@ -680,7 +680,7 @@ color.branch:: color.branch.<slot>:: Use customized color for branch coloration. `<slot>` is one of `current` (the current branch), `local` (a local branch),- `remote` (a tracking branch in refs/remotes/), `plain` (other+ `remote` (a remote-tracking branch in refs/remotes/), `plain` (other refs). + The value for these configuration variables is a list of colors (at most
@@ -1102,7 +1102,7 @@ gui.newbranchtemplate:: linkgit:git-gui[1]. gui.pruneduringfetch::- "true" if linkgit:git-gui[1] should prune tracking branches when+ "true" if linkgit:git-gui[1] should prune remote-tracking branches when performing a fetch. The default value is "false". gui.trustmtime::
@@ -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
@@ -134,7 +134,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>`
@@ -147,9 +147,9 @@ refs/heads/*:refs/remotes/origin/* ------------ A globbing refspec must have a non-empty RHS (i.e. must store-what were fetched in tracking branches), and its LHS and RHS+what were fetched in remote-tracking branches), and its LHS and RHS must end with `/*`. The above specifies that all remote-branches are tracked using tracking branches in+branches are tracked using remote-tracking branches in `refs/remotes/origin/` hierarchy under the same name. The rule to determine which remote branch to merge after
@@ -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 "remotes/<name>".
@@ -177,7 +177,7 @@ On Automatic following ~~~~~~~~~~~~~~~~~~~~~~ If you are following somebody else's tree, you are most likely-using tracking branches (`refs/heads/origin` in traditional+using remote-tracking branches (`refs/heads/origin` in traditional layout, or `refs/remotes/origin/master` in the separate-remote layout). You usually want the tags from the other end.
@@ -232,7 +232,7 @@ this case. It may well be that among networking people, they may want to exchange the tags internal to their group, but in that workflow they are most likely tracking with each other's progress by-having tracking branches. Again, the heuristic to automatically+having remote-tracking branches. Again, the heuristic to automatically follow such tags is a good thing.
@@ -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 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 master branch head as to-upstream branch at $URL". See also linkgit:git-push[1].+[[def_remote_tracking_branch]]remote-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 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 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
@@ -435,7 +435,7 @@ linux-nfs/master origin/master --------------------------------------------------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
@@ -52,7 +52,7 @@ static struct option builtin_fetch_options[] = {OPT_SET_INT('n',NULL,&tags,"do not fetch all tags (--no-tags)",TAGS_UNSET),OPT_BOOLEAN('p',"prune",&prune,-"prune tracking branches no longer on remote"),+"prune remote-tracking branches no longer on remote"),OPT_BOOLEAN(0,"dry-run",&dry_run,"dry run"),OPT_BOOLEAN('k',"keep",&keep,"keep downloaded pack"),
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:49:56
Matthieu Moy wrote:
Jonathan Nieder (1):
user-manual: remote-tracking can be checked out, with detached HEAD
Matthieu Moy (10):
Better "Changed but not updated" message in git-status
Replace "remote tracking" with "remote-tracking"
Change remote tracking to remote-tracking in non-trivial places
everyday.txt: change "tracking branch" to "remote-tracking branch"
Change "tracking branch" to "remote-tracking branch"
Change incorrect uses of "remote branch" meaning "remote-tracking"
Change incorrect "remote branch" to "remote tracking branch" in C
code
Use 'remote-tracking branch' in generated merge messages
user-manual.txt: explain better the remote(-tracking) branch terms
git-branch.txt: mention --set-upstream as a way to change upstream
configuration
Acked-by: Jonathan Nieder <redacted>
Sorry to draw this out so (and thanks for your work!).
IMHO patches 7 and 8 should be squashed to avoid breaking the
fetch/fmt-merge-msg interface, but there is no need to resend again
to make that happen.
@@ -359,6 +360,14 @@ $ git branch -r origin/todo ------------------------------------------------+In this case, "origin" is called a remote repository, or "remote" for