On Mon, Oct 29, 2012 at 6:38 AM, Jeff King <peff@xxxxxxxx> wrote: > On Mon, Oct 29, 2012 at 10:58:07AM +0100, Michael Haggerty wrote: > >> I agree with you that it is too easy to create chaos by changing tags in >> a published repository and that git should do more to prevent this from >> happening without explicit user forcing. The fact that git internally >> handles tags similarly to other references is IMO an excuse for the >> current behavior, but not a justification. > > 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? [1] http://article.gmane.org/gmane.comp.version-control.git/208473 -- -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