Re: setting up tracking on push

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 15, 2009, 18:33 UTC
Message-ID: <7v1vsy8wkp.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <4845-91917@sneakemail.com>

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

Show 15 quoted lines

> 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.