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: Wed, 19 Feb 2020 03:14:14 -0800 [thread overview]
Message-ID: <xmqqftf6hlrt.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20200219035650.GA84414@coredump.intra.peff.net> (Jeff King's message of "Tue, 18 Feb 2020 22:56:50 -0500")
Jeff King <peff@peff.net> writes:
> I think a left a few things unsaid in my "v1.0-bob" example. I was
> imagining that there are _two_ v1.0 tags floating around. One that you
> consider "wrong", tagged by Bob, and one you like. You keep the latter
> in refs/tags/v1.0.
Ahh, OK.
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:
- We can describe it based on "v1.0-bob" (i.e. refname, not
tagname), which is what the proposed patch wants to do.
This is nice as it simply exploits the fact that namespace of the
refs ensures that there can locally be only one tag "v1.0".
- We can always add "-$number-g$objectname" suffix when we need to
base the output of "git describe" on such a tag whose name does
not match its refname. Both names "v1.0-bob-0-g0123456" and
"v1.0-0-g0123456" would be accepted by get_oid() and refer to the
same object 0123456.
If we do this, there is no longer any requirement that the
"tagname" part alone of the output must be usable with get_oid()
to name the correct object, and because "v1.0-bob" is merely a
local name external people may not even know about, using
"v1.0-bob-0-g0123456" may be less desirable than using
"v1.0-0-g0123456".
- We can skip the "wrong" tag and not use it to name anything.
"git describe" may use some other tag that is stored in its right
place, which may be a bit more distant than tag "v1.0-bob". The
warning message may indicate "we would have used this tag to name
the object because it was the closest, but we skipped because of
a tagname anomaly".
This may be what the person who moved Bob's "v1.0" to "v1.0-bob"
intended---it is a "wrong" tag that is kept only to communicate
_about_ the tag, not to be used to refer to other objects
relative to it.
The "use the refname" and the "use -0-gXXXXXX suffix if using a tag
at a wrong place" approaches are simple and would produce a more
"correct" result than what we currently give. The "don't use it"
approach simply sidesteps the problem altogether, which is sort-of
attractive ;-)
next prev parent reply other threads:[~2020-02-19 11:14 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 [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqftf6hlrt.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.
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 NNTP newsgroup(s).