From: Junio C Hamano <gitster@pobox.com>
To: Kousik Sanagavarapu <five231003@gmail.com>
Cc: git@vger.kernel.org, Eli Schwartz <eschwartz@archlinux.org>,
Christian Couder <christian.couder@gmail.com>,
Hariom Verma <hariom18599@gmail.com>
Subject: Re: [PATCH] t4205: correctly test %(describe:abbrev=...)
Date: Wed, 28 Jun 2023 14:30:18 -0700 [thread overview]
Message-ID: <xmqqv8f7b7h1.fsf@gitster.g> (raw)
In-Reply-To: <20230628181753.10384-1-five231003@gmail.com> (Kousik Sanagavarapu's message of "Wed, 28 Jun 2023 23:46:59 +0530")
Kousik Sanagavarapu <five231003@gmail.com> writes:
> The pretty format %(describe:abbrev=<number>) tells describe to use only
> <number> characters of the oid to generate the human-readable format of
> the commit-ish.
Is that *only* correct? I thought it was "at least <number> hexdigits"
to allow for future growth of the project.
> This is not apparent in the test for %(describe:abbrev=...) because we
> directly tag HEAD and use that, in which case the human-readable format
> is just the tag name. So, create a new commit and use that instead.
Nice. How was this found, I have to wonder, and more importantly,
how would we have written this test in the first place to avoid
testing "the wrong thing", to learn from this experience?
> test_expect_success '%(describe:abbrev=...) vs git describe --abbrev=...' '
> - test_when_finished "git tag -d tagname" &&
> - git tag -a -m tagged tagname &&
> + test_commit --no-tag file &&
> git describe --abbrev=15 >expect &&
> git log -1 --format="%(describe:abbrev=15)" >actual &&
> test_cmp expect actual
The current test checks that the output in the case where the number
of commits since the tag is 0, and "describe --abbrev=15" and "log
--format='%(describe:abbrev=15)'" give exactly the same result.
Which is a good thing to test.
But we *also* want to test a more typical case where there are
commits between HEAD and the tag that is used to describe it.
And we *also* want to make sure that the hexadecimal object name
suffix used in the description is at least 15 hexdigits long, if not
more.
The updated test drops test #1 (which is questionable), adds test #2
(which is good), and still omits test #3 (which is not so good).
So, perhaps
test_when_finished "git tag -d tagname" &&
- git tag -a -m tagged tagname &&
test_commit --no-tag file &&
git describe --abbrev=15 >expect &&
git log -1 --format="%(describe:abbrev=15)" >actual &&
test_cmp expect actual &&
+ sed -e "s/^.*-g\([0-9a-f]*\)$/\1/" <actual >hexpart &&
+ test 16 -le $(wc -c <hexpart) &&
+
+ git tag -a -m tagged tagname &&
+ git describe --abbrev=15 >expect &&
+ git log -1 --format="%(describe:abbrev=15)" >actual &&
+ test_cmp expect actual &&
+ test tagname = $(cat actual)
or something along the line? First we test with a commit that is
not tagged at all to have some commits between the tag and HEAD with
the original comparison (this is for #2), then we make sure the
length of the hexpart (new---this is for #3), and then we add the
tag to see the "exact" case also works (this is for #1).
Thanks.
next prev parent reply other threads:[~2023-06-28 21:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-28 18:16 [PATCH] t4205: correctly test %(describe:abbrev=...) Kousik Sanagavarapu
2023-06-28 21:30 ` Junio C Hamano [this message]
2023-06-29 9:12 ` Kousik Sanagavarapu
2023-06-29 13:18 ` [PATCH v2] " Kousik Sanagavarapu
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=xmqqv8f7b7h1.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=christian.couder@gmail.com \
--cc=eschwartz@archlinux.org \
--cc=five231003@gmail.com \
--cc=git@vger.kernel.org \
--cc=hariom18599@gmail.com \
/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).