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 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@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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