From mboxrd@z Thu Jan 1 00:00:00 1970 From: Drew Northup Subject: Re: git push tags Date: Mon, 29 Oct 2012 08:25:45 -0400 Message-ID: References: <508D7628.10509@kdbg.org> <4B8097A9D6854CDFA27E7CF6574B37BA@PhilipOakley> <508E532F.2010109@alum.mit.edu> <20121029103837.GA14614@sigill.intra.peff.net> <20121029113500.GA15597@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 , Kacper Kornet To: Jeff King X-From: git-owner@vger.kernel.org Mon Oct 29 13:26:07 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 1TSoPu-0005mo-1R for gcvg-git-2@plane.gmane.org; Mon, 29 Oct 2012 13:26:06 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758901Ab2J2MZt (ORCPT ); Mon, 29 Oct 2012 08:25:49 -0400 Received: from mail-bk0-f46.google.com ([209.85.214.46]:43740 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758795Ab2J2MZq (ORCPT ); Mon, 29 Oct 2012 08:25:46 -0400 Received: by mail-bk0-f46.google.com with SMTP id jk13so1936140bkc.19 for ; Mon, 29 Oct 2012 05:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6L55sDSrdy9jw0r2zoOYIIVe+p2dT65AGnir4CmMLDs=; b=ynv9YVu43pzFAYnCGMuDuYOWwoAlo9hUlYQezSrYls7AE7t0ibY5U1O9DVqQoQC8iX /wxheyIfImnCayzQ0ktOM1eB0xYrex8ucrISDghDZCwk2b5bVyO+y95BwQ6C8V1rUMSg hWaCzYsZ+379g2tzaGYMntnF03ncTWBXrDtSJPZskGGjTg5DBhLok3gCnxCu87gyHvmj /6Q4sMp+8zw37AGUysMZ0rIdkIcsbHjQilopsGsHL168HPTnEdmP4/8oWwab1LQEH4Sl +9tsKDRraqbWrasjAXpxQsNF+JOlpVg+Eq8/CNlpVXNyHevnumaa5UVrDouHtN5F6PU8 OnNA== Received: by 10.204.11.210 with SMTP id u18mr9290024bku.123.1351513545553; Mon, 29 Oct 2012 05:25:45 -0700 (PDT) Received: by 10.205.122.144 with HTTP; Mon, 29 Oct 2012 05:25:45 -0700 (PDT) In-Reply-To: <20121029113500.GA15597@sigill.intra.peff.net> 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 7:35 AM, Jeff King 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