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;
[core]
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 1.7.9.5. 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.
Cheers,
Geoff
--
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
