git-fetch: default globally to --no-tags

Hi,

I have one main concern, and I can envision a few ways that git could
solve it. I also see that there has been some previous discussion on
reltaed topics over the years, but as far as I can tell, nothing has
actually been implemented to address my concern.

--- My concern ---

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>

The former requires extra typing for a case that (arguably) should be
the default. The latter requires configuration for each repository. This
doesn't scale well, if a user desires this behavior on all repositories
they use.

I'd prefer something like this, to change the default tag-fetching
behavior globally:

  git config --global remote.tagopt --no-tags

The closest I see is that I can disable tag-fetching globally on a
per-remote name basis:

  git config --global remote.<name>.tagopt --no-tags

This brings me to a potential bug report:

--- 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.'

--- 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.

So, my current approach is to try to limit the damage done by
accidentally fetching tags. Unfortunately, I can't find any good
supported mechanisms to help me in the previous two sections.

--- TL;DR ---

My email boils down to two questions:

  (A) Has there been progress on implementing a proposal like in [2]?

  (B) Can we allow disabling (auto)tag-fetching globally? Like:

        git config --global remote.tagopt --no-tags

Thanks,
Brian

[1] I could elaborate with some horror stories, to describe how this
    becomes a day-to-day nuisance in using git for me, but I'll avoid
    the details for now. Please accept that this is a usability bug.

[2]
    http://article.gmane.org/gmane.comp.version-control.git/165799
    http://article.gmane.org/gmane.comp.version-control.git/165885

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.

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).

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