From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Sixt Subject: Re: git filter-branch doesn't dereference annotated tags Date: Thu, 03 Jan 2013 11:33:56 +0100 Message-ID: <50E55E94.2090401@kdbg.org> References: <7vsj6mdqeo.fsf@alter.siamese.dyndns.org> <7vfw2kbs4h.fsf@alter.siamese.dyndns.org> <7vk3rwaa3r.fsf@alter.siamese.dyndns.org> <7v623f18ci.fsf@alter.siamese.dyndns.org> <50E55198.5080202@kdbg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Junio C Hamano , git@vger.kernel.org To: =?ISO-8859-1?Q?Gr=E9gory_Pakosz?= X-From: git-owner@vger.kernel.org Thu Jan 03 11:34:23 2013 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 1Tqi7u-0003RX-VY for gcvg-git-2@plane.gmane.org; Thu, 03 Jan 2013 11:34:19 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752766Ab3ACKeA convert rfc822-to-quoted-printable (ORCPT ); Thu, 3 Jan 2013 05:34:00 -0500 Received: from bsmtp1.bon.at ([213.33.87.15]:24018 "EHLO bsmtp.bon.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751583Ab3ACKd7 (ORCPT ); Thu, 3 Jan 2013 05:33:59 -0500 Received: from dx.sixt.local (unknown [93.83.142.38]) by bsmtp.bon.at (Postfix) with ESMTP id 687012C4010; Thu, 3 Jan 2013 11:33:57 +0100 (CET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by dx.sixt.local (Postfix) with ESMTP id 050F719F45D; Thu, 3 Jan 2013 11:33:57 +0100 (CET) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Am 03.01.2013 10:50, schrieb Gr=E9gory Pakosz: >> >> IOW, if the command was something like >> >> git filter-branch ...filter options... -- v1.0 master ... >> >> and v1.0 is an annotated tag, then it is reasonable to expect v1.0 t= o be >> deleted if the commit it points to goes away. But if the commit did = not >> go away, but was rewritten, then it is equally reasonable to expect = that >> the tag is also rewritten. But I don't think that we currently do th= e >> latter. >> > When the commit doesn't go away, the tag is currently being rewritten= properly. Indeed, but only if a --tag-name-filter was specified. >> Therefore, IMO, a change that implements the former behavior should = also >> implement the latter behavior. >> > The patch in my latest email does both. (yet lacks unit tests for now= ) If it deletes a tag only when --tag-name-filter was specified, than tha= t should be fine. -- Hannes