Re: setting up tracking on push

[Junio C Hamano <gitster@pobox.com>]

"John M. Dlugosz" <ngnr63q02@sneakemail.com> writes:

> Jay Soffian jaysoffian-at-gmail.com |git| wrote:
>> - The branches under refs/remotes (those shown by "git branch -r") are
>> remote tracking branches. So that tells git fetch where to fetch
>> from, which remote branches to
>> fetch, and where to store those branches locally. In this case, each
>> branch under refs/heads/ on git://git.kernel.org/pub/scm/git/git.git
>> will be fetched and stored locally as refs/remotes/origin/. Locally
>> the branches are called "remote tracking branches".
>
> Things under refs/remotes are remote tracking branches, and local
> branches (under refs/heads) that automatically updated based on a
> fetch ("store locally" means merge or rebase, right?) are also called
> remote tracking branches.
>
> I think that's why some of us are confused.

True; the latter wording invites confusion.

What fetch updates directly from remote site are called "remote tracking
branches".  The local branches you intend to keep up to date with respect
to one remote tracking branch is sometimes said to "track" the remote
tracking branch, but because I find it confusing to use the same verb for
this other purpose, I tend to say that local branch (that "tracks" the
other one)

 (1) _forked_ from; or
 (2) _builds_ on

the remote tracking branch, in order to avoid confusion.

Historically, refs/remotes/ hierarchy did not exist, and "git clone"
created these refspecs after cloning from a two branch project:

    refs/heads/master:refs/heads/origin
    refs/heads/maint:refs/heads/maint

and created a local master starting at 'origin'.

The expectation was that everybody would work on 'master', occasionally
referring to 'maint', and because 'master' is always checked out, avoid 
'fetch' from disturbing it by using a separate local branch 'origin' to
keep track of the advance of the other side, while updating 'maint' that
is not checked out directly.

This was the layout used in the good old times, and worked well *only* in
the most simplistic case.  In reality, people used far more branches and
worked on branches other than master.

To fix that, refs/remotes/ hierarchy was introduced, and we started
treating the tracking part of master the same way as other branches, i.e.

    refs/heads/*:refs/remotes/origin/*

The local 'maint' in the old layout was called a remote tracking branch,
too, even though it was local.  These days, if you use the default layout
"git clone" gives you, you can say refs under refs/remotes/ hierarchy are
all remote tracking branches, and you do not have any remote tracking
branches that are local.