On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote: > 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 think most of this problem is the way that we fetch tags straight into the refs/tags hierarchy. You would not do: [remote "origin"] fetch = +refs/heads/*:refs/heads/* prune = true unless you wanted to be a pure-mirror, because you would hose your local changes any time you fetched. But that is _exactly_ what we do with a refs/tags/*:refs/tags/* fetch. If we instead moved to a default fetch refspec more like: [remote "origin"] fetch = +refs/*:refs/remotes/origin/refs/* Then everything would Just Work. If you prune what the other side has locally, that's fine. All you're doing is pruning your view of what he has, not anything you've done locally. The tricky part is tweaking the lookup rules so that "origin/master" still works, and that looking for "v1.0" checks both refs/tags and refs/remotes/*/refs/tags. And of course managing backwards compatibility. :) In the meantime, I'd almost be tempted to say that "--prune" should refuse to work when we are touching anything outside of refs/remotes/. But that would make true mirrors fail, who do want to munge their local refs/heads/. You'd need some way to say "no, really, it's OK to prune". Maybe let remote.*.prune be "remotes", "always", or "none", and "true" maps to "remotes"? That's not backwards compatible, but it would be much safer. -Peff -- 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