From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: git push tags Date: Mon, 29 Oct 2012 07:35:00 -0400 Message-ID: <20121029113500.GA15597@sigill.intra.peff.net> References: <508D7628.10509@kdbg.org> <4B8097A9D6854CDFA27E7CF6574B37BA@PhilipOakley> <508E532F.2010109@alum.mit.edu> <20121029103837.GA14614@sigill.intra.peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Michael Haggerty , Angelo Borsotti , Philip Oakley , Chris Rorvick , Johannes Sixt , git To: Drew Northup X-From: git-owner@vger.kernel.org Mon Oct 29 12:35:24 2012 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TSncm-0001BS-C6 for gcvg-git-2@plane.gmane.org; Mon, 29 Oct 2012 12:35:20 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758770Ab2J2LfE (ORCPT ); Mon, 29 Oct 2012 07:35:04 -0400 Received: from 75-15-5-89.uvs.iplsin.sbcglobal.net ([75.15.5.89]:42675 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758766Ab2J2LfD (ORCPT ); Mon, 29 Oct 2012 07:35:03 -0400 Received: (qmail 19827 invoked by uid 107); 29 Oct 2012 11:35:45 -0000 Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7) (smtp-auth username relayok, mechanism cram-md5) by peff.net (qpsmtpd/0.84) with ESMTPA; Mon, 29 Oct 2012 07:35:45 -0400 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Mon, 29 Oct 2012 07:35:00 -0400 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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