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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.