Re: Local tag killer

[Michael Haggerty <mhagger@alum.mit.edu>]

On 09/21/2013 12:51 AM, Junio C Hamano wrote:
> Junio C Hamano <gitster-vger@pobox.com> writes:
> 
>> I also agree that the documentation is misstated; "remote-tracking branch"
>> may have been a convenient and well understood phrase for whoever wrote
>> that part, but the --prune is designed to cull extra refs in the
>> hierarchies into
>> which refs would be fetched if counterparts existed on the other side, so
>> culling tags that do not exist on the remote side should also be described.
> 
> (gleaning-leftovers mode)

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.

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/