git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Matheus Tavares <matheus.bernardino@usp.br>,
	git@vger.kernel.org, rhi@pengutronix.de
Subject: Re: [PATCH] describe: output tag's ref instead of embedded name
Date: Thu, 20 Feb 2020 09:34:36 -0800	[thread overview]
Message-ID: <xmqq4kvlcgcz.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20200220112539.GB1252160@coredump.intra.peff.net> (Jeff King's message of "Thu, 20 Feb 2020 06:25:39 -0500")

Jeff King <peff@peff.net> writes:

> On Wed, Feb 19, 2020 at 03:14:14AM -0800, Junio C Hamano wrote:
>
>> To continue playing devil's advocate and to step back a bit,
>> 
>>  - The "git describe" command finds that the given commit is
>>    "closest" to that tag Bob called "v1.0".
>> 
>>  - But if it outputs "v1.0" like the current code does, it cannot be
>>    fed back to get_oid() to name the right object, if the given commit
>>    is "at" the tag (i.e. there is no "-$number-g$objectname" suffix),
>>    which is a problem.  We want "git describe" to give an output
>>    usable with get_oid() and the name must refer to the correct
>>    object (i.e. the one given to "git describe" as an input).
>> 
>> There are multiple approaches to make it possible to feed the output
>> back to get_oid() to obtain correct result:
>> [...]
>
> Thanks for clearly laying out your thinking. All of what you wrote makes
> sense to me and I'd be OK with any of the options you described.
>
> The "-g$objectname" one is kind of clever, and definitely not something
> I had thought of. We already have "--long", and of course we'd show the
> long version for any name that isn't an exact match anyway. So as an
> added bonus, it seems unlikely to surprise anybody who is expecting the
> current "show the tag, not the refname" output (though again, this is
> rare enough that I think people simply expect them to be the same ;) ).

There is one thing you may have brought up in the discussion but I
did not touch.  Using v1.0-0-g0123456, based on tagname "v1.0" Bob
gave to it would still describe the right object, but if the user
forced "--no-long", it becomes unclear what we should do.

Saying "v1.0" like the current code does would re-introduce the
"output cannot be fed back to get_oid()" when refs/tags/v1.0 does
not exist, and when it does, get_oid() would yield a wrong object.

Another thing that is not satisfying is what should happen in "all"
mode.  We add "tags/" prefix so in the case we've been discussing,
the output would be "tags/v1.0-0-g0123456", but the whole reason why
we add the prefix is to say that the early part of the name, "v1.0",
is a tag, and it would be natural to associate it with refs/tags/v1.0
that is *not* Bob's tag.

Having said all that, here is what I have at this moment.

-- >8 --
Subject: describe: force long format for a name based on a mislocated tag

An annotated tag has two names: where it sits in the refs/tags
hierarchy and the tagname recorded in the "tag" field in the object
itself.  They usually should match.

Since 212945d4 ("Teach git-describe to verify annotated tag names
before output", 2008-02-28), a commit described using an annotated
tag bases its name on the tagname from the object.  While this was a
deliberate design decision to make it 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, it had one downside.

The output from "git describe", at least in the modern Git, should
be usable as an object name to name the exact commit given to the
"git describe" command.  Using the tagname, when two names differ,
breaks this property, when describing a commit that is directly
pointed at by such a tag.  An annotated tag Bob made as "v1.0" may
sit at "refs/tags/v1.0-bob" in the ref hierarchy, and output from
"git describe v1.0-bob^0" would say "v1.0", but there may not be
any tag at "refs/tags/v1.0" locally or there may be another tag that
points at a different object.  

Note that this won't be a problem if a commit being described is not
directly pointed at by such a mislocated tag.  In the example in the
previous paragraph, "git describe v1.0-bob~1" would result in "v1.0"
(i.e. the tagname taken from the tag object) followed by "-1-gXXXXX"
where XXXXX is the abbreviated object name, and a string that ends
with "-g" followed by a hexadecimal string is an object name for the
object whose name begins with hexadecimal string (as long as it is
unique), so it does not matter if the leading part is "v1.0" or
"v1.0-bob".

Show the name in the long format, i.e. with "-0-gXXXXX" suffix, when
the name we give is based on a mislocated annotated tag to ensure
that the output can be used as the object name for the object
originally given to the command to fix the issue.

While at it, remove an overly cautious dead code to protect against
an annotated tag object without the tagname.  Such a tag is filtered
out much earlier in the codeflow, and will not reach this part of
the code.

Helped-by: Matheus Tavares <matheus.bernardino@usp.br>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin/describe.c  | 13 ++++++++-----
 t/t6120-describe.sh | 10 +++++++++-
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/builtin/describe.c b/builtin/describe.c
index b6df81d8d0..5e8484f654 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -54,6 +54,7 @@ struct commit_name {
 	struct tag *tag;
 	unsigned prio:2; /* annotated tag = 2, tag = 1, head = 0 */
 	unsigned name_checked:1;
+	unsigned misnamed:1;
 	struct object_id oid;
 	char *path;
 };
@@ -132,6 +133,7 @@ static void add_to_known_names(const char *path,
 		e->tag = tag;
 		e->prio = prio;
 		e->name_checked = 0;
+		e->misnamed = 0;
 		oidcpy(&e->oid, oid);
 		free(e->path);
 		e->path = xstrdup(path);
@@ -275,10 +277,11 @@ static void append_name(struct commit_name *n, struct strbuf *dst)
 			die(_("annotated tag %s not available"), n->path);
 	}
 	if (n->tag && !n->name_checked) {
-		if (!n->tag->tag)
-			die(_("annotated tag %s has no embedded name"), n->path);
-		if (strcmp(n->tag->tag, all ? n->path + 5 : n->path))
-			warning(_("tag '%s' is really '%s' here"), n->tag->tag, n->path);
+		if (strcmp(n->tag->tag, all ? n->path + 5 : n->path)) {
+			warning(_("tag '%s' is externally known as '%s'"),
+				n->path, n->tag->tag);
+			n->misnamed = 1;
+		}
 		n->name_checked = 1;
 	}
 
@@ -314,7 +317,7 @@ static void describe_commit(struct object_id *oid, struct strbuf *dst)
 		 * Exact match to an existing ref.
 		 */
 		append_name(n, dst);
-		if (longformat)
+		if (n->misnamed || longformat)
 			append_suffix(0, n->tag ? get_tagged_oid(n->tag) : oid, dst);
 		if (suffix)
 			strbuf_addstr(dst, suffix);
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 45047d0a72..16a261c45d 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -130,12 +130,20 @@ test_expect_success 'rename tag A to Q locally' '
 	mv .git/refs/tags/A .git/refs/tags/Q
 '
 cat - >err.expect <<EOF
-warning: tag 'A' is really 'Q' here
+warning: tag 'Q' is externally known as 'A'
 EOF
 check_describe A-* HEAD
 test_expect_success 'warning was displayed for Q' '
 	test_i18ncmp err.expect err.actual
 '
+test_expect_success 'misnamed annotated tag forces long output' '
+	description=$(git describe --no-long Q^0) &&
+	expr "$description" : "A-0-g[0-9a-f]*$" &&
+	git rev-parse --verify "$description" >actual &&
+	git rev-parse --verify Q^0 >expect &&
+	test_cmp expect actual
+'
+
 test_expect_success 'rename tag Q back to A' '
 	mv .git/refs/tags/Q .git/refs/tags/A
 '


  reply	other threads:[~2020-02-20 17:34 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
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 [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqq4kvlcgcz.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=matheus.bernardino@usp.br \
    --cc=peff@peff.net \
    --cc=rhi@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://80x24.org/mirrors/git.git

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