remote branches

hi.

I have troubles (probably due to my misunderstanding) with git remote tracking branches. It seems to me that reality and documentation are different:

- i clone the linux git repo:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6.git

- then i add a remote tracking branch:

$ git remote add --tags drm-intel git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git

- Then i do git fetch or git fetch drm-intel, but nothing happens, and 
git branch -r still only show me origin/HEAD and origin/master, no 
drm-intel branches, though these branches do exist since i can see them 
with git remote -v show drm-intel

what am i doing wrong here, any idea? cheers,

On Sun, Feb 13, 2011 at 08:42, Matthieu Imbert <matthieu.imbert@inria.fr> wrote:

You're adding a remote repository and tracking branches and tags from it.

You didn't add any remote tracking *branch*, you added a remote and gave it the name "drm-intel". You could just as well do:

    git remote add --tags some-random-name
git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git

Also because you specified --tags you're only getting the tags on "git fetch", if you don't do that then:

    $ git fetch some-random-name
    remote: Counting objects: 567, done.
    remote: Compressing objects: 100% (377/377), done.
    remote: Total 488 (delta 371), reused 146 (delta 111)
    Receiving objects: 100% (488/488), 91.42 KiB, done.
    Resolving deltas: 100% (371/371), completed with 53 local objects.
    From git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel
     * [new branch]      drm-intel-fixes -> some-random-name/drm-intel-fixes
     * [new branch]      drm-intel-fixes-2 -> some-random-name/drm-intel-fixes-2
     * [new branch]      drm-intel-next -> some-random-name/drm-intel-next
     * [new branch]      drm-intel-staging -> some-random-name/drm-intel-staging

Which allows you to do:

    $ git checkout --track some-random-name/drm-intel-fixes
    Branch drm-intel-fixes set up to track remote branch
drm-intel-fixes from some-random-name.
    Switched to a new branch 'drm-intel-fixes'

On 02/13/2011 10:17 AM, Ævar Arnfjörð Bjarmason wrote:

You're right, the faulty option was --tags. Trying without this i was able to fetch. Thanks,

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

That's not what git-remote(1) says:

           With --tags option, git fetch <name> imports every tag from the
           remote repository.

There is no "only" in this sentence.

Andreas.

On 02/13/2011 11:08 AM, Andreas Schwab wrote:

I agree, this is what misleaded me. Perhaps the doc should be updated?

On 2011.02.13 10:17:48 +0100, Ævar Arnfjörð Bjarmason wrote:

That looks like a bug to me.

It's ok for fetch to treat --tags like a refspec and to have it override the defaults from the config when the user manually specifies it on the command line. But when it is part of the default configuration it should add to remote.<name>.fetch, not override it.

IOW with this configuration: remote.foo.url = git://host/repo.git remote.foo.fetch = +refs/heads/*:refs/remotes/foo/* remote.foo.tagopt = --tags

"git fetch foo" acts like:

git fetch --tags git://host/repo.git

instead of

git fetch --tags git://host/repo.git +refs/heads/*:refs/remotes/foo/*

And I'd argue that the latter makes a lot more sense. Also because the former could always be achieved by dropping the remote.foo.fetch config setting.

Thoughts?

Björn

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

I would agree that the behaviour of tagopt acting exactly as if the options were given from the command line is an ungly hack, not an intended behaviour. Interested in coming up with a proposed approach for a fix?

I would say --tags from the command line probably outlived its original purpose; back when we didn't have the reliable automatic following, sometimes people needed to say "fetch --tags" to complete the set of tags. The description in config.txt for --tags also cites another purpose, namely, to fetch tags otherwise totally unrelated to the branches you are following, but in reality there is no sensible use case to require such a feature. Yes, you may have many unrelated lines of development with separate set of tags on them, but then --tags to fetch _all_ tags from all of these unrelated lines of development is a too coarse-grained tool to be useful.

Note that "fetch --tags" without following any of the branches _is_ a sensible setting for a rather common workflow.

For every active developer who will have his own private changes in the repository, there would be 100 passive followers who would fetch the branches of the project and build the bleeding edge (i.e. nightly builders) and these two classes of people would benefit from having "refs/heads/*:refs/remotes/origin/*" refspec. And for each of these people, there would be 100 people who would be interested only in tagged releases. They of course could download tarballs, but they can instead say "fetch --tags", check out the latest tagged release and use it.

2011/2/14 Junio C Hamano <gitster@pobox.com>:

FWIW, here's my use case: I'm doing development on two separate computers, and I'm synchronizing my work between those by fetching from each other computer directly (not pushing through a common repo), i.e. "git remote add other b:/home/me/foo/.git" in ~/foo/.git on computer a and "git remote add other a:/home/me/foo/.git" on computer b. Now I often drop partial work, rebase it etc., and make tags before the dropping, and sometimes I want to revisit those tagged (but not otherwise reachable) commits, and for that I want them to be available on both computers. I too searched the config docs, tried "tagopts = --tags" and then wondered why it wouldn't sync my branches anymore, then moved to "fetch = +refs/tags/*:refs/tags/*".

Christian.