On Fri, 20 Jan 2012 07:01:27 -0800 (PST)
dspfun <dsp...@hotmail.com> wrote:
> A confusing thing is the difference between:
> >git log master
> >git log origin/master
> "git log master" shows the log of the remote repositorys master
> "git log origin/master" shows the log of a _local_ branch which is
> tracking a remote branch (it is tracking the "origin master" branch,
> and the local tracking branch is only updated when a "git fetch" is
The confusing thing about Git branches is that *physically* they are all
local--when you run `git log $branch` Git does not contact any remote
repositories to fetch the chain of that branch's commits: all data is
The distinction between "local" ("really" local, that is, usually
created by you) and "remote" branches is just a policy about naming
and handling. When you clone a remote repository, Git brings in all the
remote branches, but it creates them in your local repository using a
special naming scheme: it constructs their names by concatenating the
remote's name and the branch name, so the "master" branch in the remote
repo known to Git as "origin" becomes "origin/master" locally and so
on. (That "origin" name is just a default remote name Git uses when you
do `git clone`--you can have any number of remotes with different
Now the idea is that later fetches from the same remote just update
already existing remote branches (and create new ones, when needed).
You never develop on such branches--they're just here for you to
represend the state of the remote repository.
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"
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`. You can merge
it into your branch "master", you can rebase your branch "master" onto
it and so on but essentially you treat it as being read-only and only
indicating how the branch "master" looks like in the remote repository.
It may help to know that some other DVCSes (I know of Mercurial
and Fossil) maintain a different concept about branches: in these
systems, a branch might have multiple heads (or leaves) in a local
repository. Contrary to this, a branch in Git only has one head (or
tip), that's why when it comes to tracking remote repositories their
branches are tracking using separate branches in your local repository.
Probably you should read up on remote branches  now.
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 firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at