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

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

Reply via email to