On Tue, Sep 27, 2011 at 01:28:09AM +0200, Carlos Martín Nieto wrote:
> > term I think we should fix it properly. We are already learning "what are
> > the refs the remote side currently has" from the transport and the right
> > fix ought to be to use that original information, not the version filtered
> > for the use of the primary objective of fetch, which is to only fetch what
> > the user asked for.
>
> Do you mean that we should ignore the refspec? Or do you mean that we
> should look at the refspec if it exists, and only consider deleting
> those that meet the refspec, so that `--prune --tags` would only delete
> tags that don't exist in the remote?
The latter. If I say:
git fetch --prune origin refs/heads/master:refs/remotes/origin/master
and refs/heads/master doesn't exist on the remote, I would expect
refs/remotes/origin/master to be deleted locally. And that naturally
extends to:
git fetch --prune origin refs/heads/*:refs/remotes/origin/*
We do something similar with "git push --mirror", which does pruning
like this[1].
-Peff
[1] Actually, I'm not sure how correct "push --mirror" is. It would be
nice if the prune operation could be split from the mirror, too. In
the past, I have wanted to do both:
# backup to a repository where our objects will be shared
# with other related backups. So we must only use our slice of the
# ref namespace.
git push --mirror backup-repo +refs/*:refs/`hostname`/*
and:
# update topic branches we have already published (using the
# "matching" refspec), but remove any that we have deleted
# locally.
git push --mirror publish-point +:
and I don't think either works.
--
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