On Sat, Sep 21, 2013 at 2:42 AM, Michael Haggerty <mhag...@alum.mit.edu> wrote:
> On 09/21/2013 12:51 AM, Junio C Hamano wrote:
>> Junio C Hamano <gitster-v...@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".
> 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 , 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html