I have some peculiar reasons for doing this, but nonetheless I don't
believe there's anything illegal here. I have a repo with a bunch of
remotes set up to pull in branches and tags from different places, and
I need all those branches and tags name-spaced. Eg. to illustrate, the
config looks something like;

        repositoryformatversion = 0
        filemode = true
        bare = true
[remote "foo"]
        url = git://some.address/foo
        fetch = +refs/heads/*:refs/remotes/foo/heads/*
        fetch = +refs/tags/*:refs/remotes/foo/tags/*
[remote "bar"]
        url = git://somewhere.else/bar
        fetch = +refs/heads/*:refs/remotes/bar/heads/*
        fetch = +refs/tags/*:refs/remotes/bar/tags/*

If I do "git fetch --no-tags foo && git fetch --no-tags bar",
everything's fine - all the branches and tags from "foo" sit under
refs/remotes/foo/{heads,tags}/, and similarly for "bar". OTOH, if I do
"git fetch --all --no-tags", it's as though the --no-tags wasn't
there. Inverting the argument order doesn't seem to help.

What this means is that in addition to putting branches and tags in
the locations specified in the refspecs, it also puts copies of all
the tags in refs/tags/. In my case, "foo" and "bar" will sometimes
define the same tag name but they don't refer to the same thing,
that's (one of the reasons) why I need them name-spaced. The current
situation with "--all" is that refs/tags/ contains an ad-hoc union of
tags from the different remotes, and if there are any collisions they
seem to resolve in favour of whichever was fetched last.

So instead of doing;
    git fetch --all --no-tags
I'm now doing this to avoid the problem;
    git remote | xargs -n 1 git fetch --no-tags

BTW, I've hit this problem on a system I don't administer, so I can't
easily verify this with the latest source. It's a ubuntu system and
"git --version" indicates Apologies in advance if this is
just noise about an already-fixed-bug, but I didn't find anything via
a quick search (of the mail-list and the net more generally) so
figured I'd send this in.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to