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