Re: setting up tracking on push

[Jay Soffian <jaysoffian@gmail.com>]

On Sat, Mar 14, 2009 at 11:28 PM, John M. Dlugosz
<ngnr63q02@sneakemail.com> wrote:

> Things under refs/remotes are remote tracking branches

Yes.

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

No. The branches under refs/heads are *not* [1] updated by fetch.

- Anything under refs/remotes is a remote tracking branch.
- Anything under refs/heads is a local branch.

Now, often local branches are based on remote tracking branches, in the
sense that you created the local branch _from_ the remote tracking
branch. So periodically, you will want to update the local branch in
order to incorporate your local changes with whatever changes have been
made in the remote tracking branch. Doing this is a two-step process:

1) You update your remote tracking branches using fetch.
2) You integrate the changes from the remote tracking branches into your
   local branches using either merge or rebase.

> I think that's why some of us are confused.

I remember being just as confused, but oddly it seems so clear to me
now. I think there is an inflection point where git goes from
"confusing" to "ah hah, it's ingenious!" :-)

Let me try to draw a little ascii art:

Local Repo                                  Remote Repo (origin)
----------                                  --------------------
refs/remotes/origin/master  <-- fetch ---   refs/heads/master
        |
(merge or rebase)
        |
        v
refs/heads/master

As changes are made to refs/heads/master on the remote repo, the
corresponding remote tracking branch on the local repo
(refs/remotes/origin/master) will fall behind. Performing a fetch in the
local repo updates its refs/remotes/origin/master to match the remote's
refs/heads/master. Then either merge or rebase in the local repo, while
refs/heads/master is checked out, integrates those changes.

If no changes have been made locally to refs/heads/master, then the
merge operation is a so-called "fast forward".

The confusing part is that there is a switch to "git checkout" and "git
branch" named "--track". A better name would have probably been
"--follow". Regardless, this switch [2], configures branch.<name>.remote
and branch.<name>.merge in the local repo's .git/config. And I mentioned
in a previous message the reason for having these. [3]

[1] You could of course configure fetch to do whatever you like, but it
    would be rather unusual to update refs/heads via fetch.
[2] Which is the default in current git when a local branch is created
    from a remote tracking branch.
[3] Namely, 1) branch -v, status, and checkout tell you how far
    ahead/behind the local branch is from the remote tracking branch;
    2) pull can be run w/o having to explicitly tell it what to fetch
    and what to merge.

j.