Re: Terminology question about remote branches.

Theodore Tso [off-list ref] writes:

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

quoted

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:

Yes, I noticed.  I can do a
git-clone -l --reference /my/local/rep git://the/remote/repo

instead.  That's still very fast, but I miss out on my local changes...

[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

quoted

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.

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.

An error message might be nice, though.  I find git hard to understand
at times.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum