On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote: > > I would have expected git to at least complain about updating an > > annotated tag with another annotated tag. But it actually uses the same > > fast-forward rule, just on the pointed-to commits. So a fast-forward > > annotated re-tag will throw away the old tag object completely. Which > > seems a bit crazy to me. > > > > It seems like a no-brainer to me that annotated tags should not replace > > each other without a force, no matter where in the refs hierarchy they > > go. > > > > For lightweight tags, I think it's more gray. They are just pointers > > into history. Some projects may use them to tag immutable official > > versions, but I also see them used as shared bookmarks. Requiring "-f" > > may make the latter use more annoying. On the other hand, bookmark tags > > tend not to be pushed, or if they are, it is part of a mirror-like > > backup which should be forcing all updates anyway. > > Would that be an endorsement of continuing to build a patch set > including the snippet that Kacper posted earlier (1) in response to my > comment about not being sure how complicated all of this would be or > not? That patch just blocks non-forced updates to refs/tags/. I think a saner start would be to disallow updating non-commit objects without a force. We already do so for blobs and trees because they are not (and cannot be) fast forwards. The fact that annotated tags are checked for fast-forward seems to me to be a case of "it happens to work that way" and not anything planned. Since such a push drops the reference to the old version of the tag, it should probably require a force. Then on top of that we can talk about what lightweight tags should do. I'm not sure. Following the regular fast-forward rules makes some sense to me, because you are never losing objects. But there may be complications with updating tags in general because of fetch's rules, and we would be better off preventing people from accidentally doing so. I think a careful review of fetch's tag rules would be in order before making any decision there. -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