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.
