mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Jeff King <>
Cc: Matheus Tavares <>,,
Subject: Re: [PATCH] describe: output tag's ref instead of embedded name
Date: Tue, 18 Feb 2020 19:22:02 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Jeff King's message of "Tue, 18 Feb 2020 20:57:33 -0500")

Jeff King <> writes:

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

Yes, and that can be done by either (1) locally moving a tag that is
stored in a wrong location to where it wants to be, or (2) locally
*creating* a tag that suits the preferences of the local repository,
ignoring the tag obtained from outside world that is stored in a
wrong place.  The latter would not help to facilitate communication,

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

That you can do with "git tag v1.0-bob <whatever object>" locally, no?

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

Yeah, I do not think this is an often-arising concern.  It's merely
what the expected and recommended direction to escape when it
happens, and what the warning message should say to make the
recommendation communicated better, I think.

Note that I started this to play a devil's advocate.  As an object
is immutable, while it can be named with any refname, if easing
communication between project participants is one of the goals, it
seems that taking what is in the object as authoritative is the only
workable way.

  reply	other threads:[~2020-02-19  3:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-05 14:13 git-describe --tags warning: 'X' is really 'Y' here Roland Hieber
2020-02-05 17:15 ` Matheus Tavares Bernardino
2020-02-14  6:53   ` Jeff King
2020-02-14 16:57     ` Junio C Hamano
2020-02-15 21:34       ` [PATCH] describe: output tag's ref instead of embedded name Matheus Tavares
2020-02-16  6:51         ` Jeff King
2020-02-18 19:31           ` Junio C Hamano
2020-02-18 19:54             ` Jeff King
2020-02-18 23:05               ` Junio C Hamano
2020-02-18 23:28                 ` Junio C Hamano
2020-02-19  1:57                   ` Jeff King
2020-02-19  3:22                     ` Junio C Hamano [this message]
2020-02-19  3:56                       ` Jeff King
2020-02-19 11:14                         ` Junio C Hamano
2020-02-20 11:25                           ` Jeff King
2020-02-20 17:34                             ` Junio C Hamano
2020-02-20 22:19                               ` Matheus Tavares Bernardino
2020-02-20 22:59                                 ` Junio C Hamano
2020-02-21  1:33                                   ` Matheus Tavares
2020-02-21  2:05                                     ` Junio C Hamano
2020-02-21  6:00                                       ` Jeff King
2020-02-21  5:58                               ` Jeff King
2020-02-19 10:08                       ` Roland Hieber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).