Re: Terminology question about remote branches.

From: Theodore Tso <tytso@mit.edu>
Date: Aug 4, 2007, 22:56 UTC
Message-ID: <20070804225655.GD11150@thunk.org>
In-Reply-To: <85hcnfdvtr.fsf@lola.goethe.zz>

On Sat, Aug 04, 2007 at 08:00:00PM +0200, David Kastrup wrote:

Show 5 quoted lines

> 
> I think I am going to cry.  So I need to rebase my branches, pull out
> the resulting patch sets, scrap my repository, clone it new from
> upstream, reapply my branches, in order to have a system where the
> documentation is somewhat in synch with the actual behavior?

... or you can you use "git remote" to create the remote tracking branches. The important thing to realize is that 99% of what "git remote" does is purely by editing the config file. (The last 1% is running "git fetch" if you specify the -f option.) So understanding what gets placed in the .git/config file after doing an initial clone from a URL for a pre-1.5 git and what gets placed in .git/config file and how the branches are set up post 1.5 is key to understanding what is going on.

> No, it would seem that I can just
> git-clone -l
> my repository and be set up in the new order of things.  Nice.

Be careful, not really. A git-clone -l will set up a new repository where origin/master is your original repository, i.e.:

[remote "origin"]
        url = /usr/projects/e2fsprogs/base
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

In contrast, if you had done a git-clone of remote repository, you might see something like this instead:

[remote "origin"]
        url = git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

In contrast, if you are using git 1.4, after a clone, "origin" and "master" are by default set to the "master" branch in the source repository, and in git 1.4 (and in git 1.5 if you don't have any of the above configuration opions in your .git/config file), the "origin" branch is magical and works like the remote tracking branch of origin/master of git 1.5 for the purposes of "git fetch", and then the implied merge done by "git pull" merges from "origin" branch to the "master" branch.

> However, it would appear from my experiments up to now that the
> --track option _can't_ be made to work with a 1.4 repository.  I think
> that is worth mentioning in the docs.

Well, there really is no such thing as a "1.4 repository". The only real difference is the default configuration which is dropped into the .config file when you do a "git clone", and whether the head of the master branch created after the "git clone" is called "origin", with some magic special casing so that works like a remote tracking branch of the remote repo's master branch, or whether it is called "origin/master", with explicit configuration rules in .git/config.

The real issue is that a "1.4 repository" (that is a repository created by "git clone" from git 1.4 and where the config file hasn't been updated either by hand-editing the config file or by use of "git config" or "git remote" to have remote branches) doesn't have any remote branches, and git branch -track only has significance if you are creating a new (local) branch from a remote tracking branch.

Regards,

						- Ted