From: "René Scharfe" <l.s.r@web.de>
To: Derrick Stolee <stolee@gmail.com>, Git List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Jonathan Tan <jonathantanmy@google.com>
Subject: Re: Git Test Coverage Report (v2.27.0-rc0)
Date: Tue, 19 May 2020 22:07:00 +0200 [thread overview]
Message-ID: <e0a0fc10-7141-f456-a6db-8d2b8c7dc6b9@web.de> (raw)
In-Reply-To: <853759d3-97c3-241f-98e1-990883cd204e@gmail.com>
Am 19.05.20 um 14:11 schrieb Derrick Stolee:
> On 5/15/2020 1:22 PM, Derrick Stolee wrote:
>> René Scharfe 9068cfb2 fsck: report non-consecutive duplicate names in trees
>> fsck.c
>> 9068cfb2 623) break;
>> 9068cfb2 626) if (is_less_than_slash(*p)) {
>> 9068cfb2 627) name_stack_push(candidates, f_name);
>> 9068cfb2 628) break;
>> 9068cfb2 630) }
>
> These are different conditions in verify_ordered() to check the
> special case of blobs and trees having the "same" name (but
> sorted differently due to appending '/' to trees before sorting).
>
> There is another name_stack_push() that _is_ covered. I wonder
> what case would trigger this push?
Our test has one entry between the conflicting two:
x
x.1
x/
The branch is necessary if the check of a candidate tree consumes
a candidate file from the stack that we need to check against later
candidate trees, e.g.:
x
x.1.2
x.1/
x/
Let's check each in sequence:
1. "x" is a candidate file because the next entry starts with "x" +
less-than-slash, so "x/" can still follow. We push it onto the
stack.
2. "x.1.2" is not a candidate. A hypothetical "x.1.2/" would come
before "x.1/", so we can be sure we don't have it.
3. "x.1/" is a candidate tree because it follows an entry that starts
with "x.1" + less-than-slash, so we could have seen a file named
"x.1" earlier. We pop "x" from the stack and see that it doesn't
match, but is a prefix. "x.1/" is "x" + less-than-slash, so "x/"
can still follow. We push it back onto the stack. And that's
the branch in question.
4. "x/" is a candidate tree because it follows an entry that starts
with "x" + less-than-slash, so we could have seen a file named "x"
earlier. We pop "x" from the stack, and have a match.
But here's one that slips by fsck and the test coverage check:
x
x.1
x.1.2
x/
This duplicate is not caught by the current code. Both "x" and "x.1"
are candidate files. "x.1.2" is not a candidate. "x/" is checked
against "x.1" from the top of the stack, found not to be a prefix and
the search ends at that point, unsuccessfully. I think we need this to
fix it:
diff --git a/fsck.c b/fsck.c
index 8bb3ecf282..594e800015 100644
--- a/fsck.c
+++ b/fsck.c
@@ -620,7 +620,7 @@ static int verify_ordered(unsigned mode1, const char *name1,
if (!f_name)
break;
if (!skip_prefix(name2, f_name, &p))
- break;
+ continue;
if (!*p)
return TREE_HAS_DUPS;
if (is_less_than_slash(*p)) {
next prev parent reply other threads:[~2020-05-19 20:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 17:22 Git Test Coverage Report (v2.27.0-rc0) Derrick Stolee
2020-05-19 12:11 ` Derrick Stolee
2020-05-19 20:07 ` René Scharfe [this message]
2020-05-19 23:42 ` brian m. carlson
2020-05-20 1:38 ` brian m. carlson
2020-05-19 18:31 ` [PATCH] t4067: make rename detection test output raw diff Jonathan Tan
2020-05-19 19:00 ` Derrick Stolee
2020-05-20 1:41 ` [PATCH 1/1] builtin/checkout: simplify metadata initialization brian m. carlson
2020-05-20 15:17 ` Junio C Hamano
2020-05-20 22:37 ` brian m. carlson
2020-05-21 2:07 ` [PATCH v2 0/2] Improve Fix code coverage for checkout brian m. carlson
2020-05-21 2:07 ` [PATCH v2 1/2] builtin/checkout: simplify metadata initialization brian m. carlson
2020-05-21 17:35 ` Junio C Hamano
2020-05-23 12:22 ` brian m. carlson
2020-05-21 2:07 ` [PATCH v2 2/2] t2060: add a test for switch with --orphan and --discard-changes brian m. carlson
2020-05-21 12:38 ` [PATCH v2 0/2] Improve Fix code coverage for checkout Derrick Stolee
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=e0a0fc10-7141-f456-a6db-8d2b8c7dc6b9@web.de \
--to=l.s.r@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonathantanmy@google.com \
--cc=sandals@crustytoothpaste.net \
--cc=stolee@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.
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).