On Tue, Nov 18, 2014 at 07:05:23PM -0800, Brian Norris wrote: > When I fetch from a remote repository, the only ways to > prevent fetching tags are: > > 1) git fetch --no-tags <name> > > 2) git config remote.<name>.tagopt --no-tags; git fetch <name> Yes, there is no way to globally specify --no-tags. I don't see it as a problem to add something like that. > The former requires extra typing for a case that (arguably) should be > the default. I don't understand this assumption, though. Why don't you want to fetch tags from the remote side? Wouldn't this break something as simple as: git clone git://git.kernel.org/pub/scm/git/git.git cd git git checkout v2.1.3 (Actually, no, it wouldn't, because clone side-steps the usual tag-following procedure, but wouldn't you expect the same thing to work after a fetch in an existing repository?) (And now having read all the way to the bottom of your email, I at least see why you dislike tags. But I am not convinced that turning them off completely does not come with its own set of usability problems). > I'd prefer something like this, to change the default tag-fetching > behavior globally: > > git config --global remote.tagopt --no-tags Yeah, that would make sense to me (I do not know _why_ you would want to do it, but it would be consistent with other parts of git). If you are adding a new config option, though, please do not follow the odd and confusing "tagopt" config value, and make a boolean remote.autofollowtags or something. > --- Bug --- > > When trying to use the remote.<name>.tagopt configuration option > globally, I get something like this: > > $ git config --global remote.test.tagopt --no-tags > $ git remote update > ... > Fetching test > fatal: 'test' does not appear to be a git repository > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > error: Could not fetch test > ... > > Expected behavior: if the local repository does not have a remote named > 'test', then no additional output should be printed. If the local > repository has a remote named test, then it should be fetched with the > --no-tags option. > > Actual behavior: git prints warnings about the 'test' remote, just > because there is no remote named 'test.' That is the expected behavior (sort of). Any time you define a single key in a remote, that remote "exists", whether there is a remote.*.url key for it or not. You can use that to set options for remotes you specify only as a URL, though I do not know how widely-used that feature is. IOW, git is not complaining here that there is no remote named 'test'. It is complaining that you have defined a remote called 'test', whose URL defaults to 'test' (because you did not specify one in the config), and that there is no repo called test. If you defined it as: git config --global remote.git://github.com/git/git.tagopt --no-tags that would "work" in the sense that "git remote update" would download git in every repository. ;) I think one could argue that "git remote update" should probably skip remotes for which no url is defined (but we _do_ still want to treat them as remotes internally, so that when you "git fetch ...", we apply the config correctly). > --- Motivations --- > > This is all motivated by the fact that tag namespacing is completely > broken in git. Tags are globally namespaced, and in a true DVCS > environment, any particular developer has no control over another > developer's tag naming conventions. So this namespace can easily become > polluted, reducing the usefulness of tags as a whole [1]. This problem > seems to have been acknowledged, and proposals appeared a few years ago > [2]. But I don't see any solution for tag namespacing. I don't know if I would say "completely broken", as it mostly gets the job done. But yes, there are other ways of doing it that would have advantages. > My email boils down to two questions: > > (A) Has there been progress on implementing a proposal like in [2]? Not really, no. If you'd like to work on it, I'm sure people would be happy to review patches. > (B) Can we allow disabling (auto)tag-fetching globally? Like: > > git config --global remote.tagopt --no-tags That seems reasonable to me to use remote.* as defaults for all remotes. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html