Re: git push tags

From: Jeff King <peff@peff.net>
Date: Oct 29, 2012, 10:38 UTC
Message-ID: <20121029103837.GA14614@sigill.intra.peff.net>
In-Reply-To: <508E532F.2010109@alum.mit.edu>

On Mon, Oct 29, 2012 at 10:58:07AM +0100, Michael Haggerty wrote:

Show 5 quoted lines

> 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.

-Peff