From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id CDDEB1F45E for ; Wed, 19 Feb 2020 01:57:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728069AbgBSB5f (ORCPT ); Tue, 18 Feb 2020 20:57:35 -0500 Received: from cloud.peff.net ([104.130.231.41]:47556 "HELO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1727811AbgBSB5e (ORCPT ); Tue, 18 Feb 2020 20:57:34 -0500 Received: (qmail 21345 invoked by uid 109); 19 Feb 2020 01:57:31 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with SMTP; Wed, 19 Feb 2020 01:57:31 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 24171 invoked by uid 111); 19 Feb 2020 02:06:35 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Tue, 18 Feb 2020 21:06:35 -0500 Authentication-Results: peff.net; auth=none Date: Tue, 18 Feb 2020 20:57:33 -0500 From: Jeff King To: Junio C Hamano Cc: Matheus Tavares , git@vger.kernel.org, rhi@pengutronix.de Subject: Re: [PATCH] describe: output tag's ref instead of embedded name Message-ID: <20200219015733.GA81560@coredump.intra.peff.net> References: <20200216065101.GA2937208@coredump.intra.peff.net> <20200218195402.GA21586@coredump.intra.peff.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, Feb 18, 2020 at 03:28:24PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > Coming back to the original topic, ... > > > >> If a tag describes a commit, we currently output not the tag's ref but > >> its embedded name. This means that when the tag is locally stored under > >> a different name, the output given cannot be used to access the tag in > >> any way. A warning is also emitted in this case, but the message is not > >> very enlightening: > > > > None of the above is wrong per-se, but the reason why we chose to > > use the real name of the tag in the tag object, while issuing a > > warning, was so that people can correct the mistake of storing an > > annotated tag A to a wrong refname Q. If "describe" gave a name > > based on refname Q, there is no incentive to correct the situation > > to use the right refname. The name that describes the commits > > relative to the real name of the A is *not* usable by design, until > > the refname is corrected (i.e. the tag is stored in the right > > place). > > > > So I am not 100% confident that the original patch is a good idea. > > FWIW, this design came from 212945d4 ("Teach git-describe to verify > annotated tag names before output", 2008-02-28). Shawn was quite > explicit that use of the real name was deliberate: > > If an annotated tag describes a commit we want to favor the name > listed in the body of the tag, rather than whatever name it has > been stored under locally. By doing so it is easier to converse > about tags with others, even if the tags happen to be fetched to > a different name than it was given by its creator. > > and I tend to agree with the original rationale. Thanks, I should have dug into the history in the first place. Still, I'm not entirely convinced. As a decentralized system, I think our first duty is to make things convenient and workable for the preferences of the local repository, and second to facilitate communication with other people's clones of the same repository. If for whatever reason I chose to call my version of the global v1.0 tag as "v1.0-bob", then it seems friendlier to me to report the name that can actually be used with further local commands (and remind the user of the global name) than the other way around. Though TBH the situation is rare enough that I kind of doubt it matters all that much either way. It's been like this for over a decade, and this is the first time I recall it being brought up. -Peff