Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
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
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)) {


  reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-15 17:22 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

* 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

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git