Re: Local tag killer

On 09/21/2013 12:51 AM, Junio C Hamano wrote:

Thanks for following up on this with your proposed documentation patch.
 I have been researching and experimenting, and still find the use of
fetch confusing with respect to tags.  I think the problem is primarily
that the behavior is awkward, and that it would be better to change the
behavior than to document the awkward behavior.

I must have read an old version of the documentation, from which it seemed that "git fetch --tags" fetches all tags from the remote *in addition to* the references and tags that would otherwise be fetched. This seems like a handy and safe feature, and I wish that this were indeed the effect of "--tags".

But I see that the documentation for "--tags" has been changed and now
states explicitly that "--tags" is equivalent to specifying
"refs/tags/*:refs/tags/*" on the command line, overriding any configured
refspecs.  This doesn't seem like useful behavior; why would I want to
fetch tags from a remote without also updating the configured refspecs?
 And contrariwise, how can I fetch the configured refspecs *and* all
tags at the same time in a single fetch?

OK, one way to do it is to configure an explicit refspec for fetching the tags:

[remote "origin"]
	url = [...]
	fetch = +refs/heads/*:refs/remotes/origin/*
	fetch = refs/tags/*:refs/tags/*

[Here is one oddity: even if the tags refspec doesn't have a "+" prefix, "git fetch" will do non-ff updates to tags, presumably because of the implicit tag-fetching behavior.]

But if I use this configuration and type "git fetch --prune", then any local tags that are not present on the remote will be killed.

In short, when local tags are in use, or tags that are in one remote but not another [1], then the current Git implementation makes it impossible to

- Configure "fetch.prune" or "remote.$REMOTE.prune" without preventing
the use of "fetch --tags"

- Configure default fetching of all tags (via a refspec or via
remote.$REMOTE.tagopt) without preventing the use of "fetch --prune"

- Configure "fetch.prune" or "remote.$REMOTE.prune" and the default
fetching of all tags (via a refspec or via remote.$REMOTE.tagopt) at the
same time.

This is unfortunate.

I think it would be preferable if "--prune" would *not* affect tags, and if there were an extra option like "--prune-tags" that would have to be used explicitly to cause tags to be pruned. Would somebody object to such a change?

Michael

[1] In fact, the scenario that bit my colleague was as follows: he had just built a software release, which creates a new commit and a release tag. When he tried to push the commit, there was a non-ff failure due to an upstream change. So he ran "git fetch --prune" to get the upstream change, and this caused the release tag (which hadn't been pushed yet) to be lost.