On Mon, Oct 29, 2012 at 7:35 AM, Jeff King <peff@xxxxxxxx> wrote: > 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 Thanks, I had the sinking suspicion that this was going to be more complicated. -- -Drew Northup -------------------------------------------------------------- "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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