Re: Local tag killer

[John Szakmeister <john@szakmeister.net>]

On Sat, Sep 21, 2013 at 2:42 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> 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 agree with this sentiment.  I've never liked how `--tags` operates.

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

Me too.

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

I, personally, think what you outline makes more sense.  Also, I'm
curious if `git remote update -p $REMOTE` suffers from the same
problem, if the remote was added with the `--tags` option.

-John