On Sat, 21 Jan 2012 14:43:13 -0800 (PST)
dspfun <dsp...@hotmail.com> wrote:

[...]
> > The fact you have a local branch "master" after cloning a remote repo
> > is because, in essence, `git clone` works like this:
> > 1) Initializes an empty local repository.
> > 2) Fetches into it all the branches the remote has, creating
> >    local "remote branches" using the naming scheme described above.
> >    Say, if the remote has branches "foo", "bar" and "master", your local
> >    repository will end up having branches "origin/foo", "origin/bar"
> >    and "origin/master".
> > 3) Asks the remote about which branch it has as its current branch
> >    and then creates a normal local branch of the same name which
> >    is then "set to track" the matching remote branch (let's not
> >    try to cover this topic right now to not add into confusion).
> >    Say, if the remote has the branch "master" as its current branch,
> >    you will get the normal local branch "master" which is set to
> >    track the branch "origin/master".
> >    This branch is then checked out to your work tree.
> >
> > Now when after cloning you have a branch named "master" in your
> > repository, it's *your* branch "master", on which you do *your*
> > development.  The "origin/master" branch just tracks the state of the
> > "master" branch in the remote repository, you never do any development
> > on it, it's just updated when you run `git fetch`.
> 
> Thanks for the info! If I understand things correctly the previous
> sentence is not correct. Instead, it is the master branch that tracks
> the origin/master branch, from "pro git":
> "When you clone a repository, it generally automatically creates a
> master branch that tracks origin/master."
The previous sentence is correct, it's just another thing about how "local" and 
"remote" branches may relate to each other in your local repository,
the thing I tried to sidestep in my original response to keep it simpler.
May be that wasn't a good idea.

The fact is, a branch in a Git repository can be assigned a property of 
tracking another branch, which is most typically a remote branch.
The idea is to let Git know that a particular branch is related with regard to 
development being done on it to another branch.
When you fork a branch from a remote branch (say, by doing
`git branch foo origin/foo`), the newly created branch "foo" is automatically
"set to track" the branch "origin/foo".  Tracking is useful as it allows Git to 
employ common sense in some cases, for instance, when you do `git push` while 
having such a tracking branch checked out, Git knows what branch in what remote 
repo to update with commits made on this local branch.  Git will also
hint you about whether your tracking branch is ahead/behind the remote branch 
it tracks when you do things like `git status` or `git checkout`.
As you can see, like with the distinction between remote and local branches, 
this thing about tracking is also just a policy obeyed by certain Git tools.

Now there's a terminological issue: when you clone a repo which has a branch 
named "master" and this branch is active in that repo, Git creates in your 
local repo a remote branch named "origin/master" and then a normal branch named 
"master" which is made to track the branch "origin/master".
Here the term "tracking" refers to the Git's machinery described above.

But the remote branch "origin/master" also tracks the state of the branch named 
"master" in the remote repo: this means when you do `git fetch`, Git
will update that "origin/master" branch so that its line of history precisely
matches the state of the branch "master" in the remote repo: whenever someone 
pushes something to the branch "master" in the repote repo and you then fetch 
from that remote, your "origin/master" branch will be updated.
If you don't like the term "tracks" for this case, you can use anything 
matching like "follows".

Sorry for provoking a confusion.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to