From: Jonathan Nieder <jrnieder@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH 5/7] t0060: test obscured .gitattributes and .gitignore matching
Date: Mon, 5 Oct 2020 01:03:53 -0700 [thread overview]
Message-ID: <20201005080353.GH1166820@google.com> (raw)
In-Reply-To: <20201005072102.GE2291074@coredump.intra.peff.net>
(+cc: Dscho for NTFS savvy)
Jeff King wrote:
> We have tests that cover various filesystem-specific spellings of
> ".gitmodules", because we need to reliably identify that path for some
> security checks. These are from dc2d9ba318 (is_{hfs,ntfs}_dotgitmodules:
> add tests, 2018-05-12), with the actual code coming from e7cb0b4455
> (is_ntfs_dotgit: match other .git files, 2018-05-11) and 0fc333ba20
> (is_hfs_dotgit: match other .git files, 2018-05-02).
>
> Those latter two commits also added similar matching functions for
> .gitattributes and .gitignore. These ended up not being used in the
> final series, and are currently dead code. But in preparation for them
> being used, let's make sure they actually work by throwing a few basic
> checks at them.
>
> I didn't bother with the whole battery of tests that we cover for
> .gitmodules. These functions are all based on the same generic matcher,
> so it's sufficient to test most of the corner cases just once.
Yeah, that's reasonable.
> Note that the ntfs magic prefix names in the tests come from the
> algorithm described in e7cb0b4455 (and are different for each file).
Doesn't block this patch, but I'm curious: how hard would it be to make
a test with an NTFS prerequisite that makes sure we got the magic prefix
right?
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> t/helper/test-path-utils.c | 41 ++++++++++++++++++++++++++------------
> t/t0060-path-utils.sh | 20 +++++++++++++++++++
> 2 files changed, 48 insertions(+), 13 deletions(-)
>
> diff --git a/t/helper/test-path-utils.c b/t/helper/test-path-utils.c
> index 313a153209..9e253f8058 100644
> --- a/t/helper/test-path-utils.c
> +++ b/t/helper/test-path-utils.c
> @@ -172,9 +172,22 @@ static struct test_data dirname_data[] = {
> { NULL, NULL }
> };
>
> -static int is_dotgitmodules(const char *path)
> +static int check_dotgitx(const char *x, const char **argv,
> + int (*is_hfs)(const char *),
> + int (*is_ntfs)(const char *))
> {
> - return is_hfs_dotgitmodules(path) || is_ntfs_dotgitmodules(path);
> + int res = 0, expect = 1;
> + for (; *argv; argv++) {
> + if (!strcmp("--not", *argv))
> + expect = !expect;
> + else if (expect != (is_hfs(*argv) || is_ntfs(*argv)))
> + res = error("'%s' is %s.%s", *argv,
> + expect ? "not " : "", x);
> + else
> + fprintf(stderr, "ok: '%s' is %s.%s\n",
> + *argv, expect ? "" : "not ", x);
micronit: extra space on the "res" line.
This "if" cascade is a little hard to read, even though it does the
right thing. Can we make it more explicit? E.g.
if (!strcmp("--not", *argv)) {
expect = !expect;
continue;
}
actual = is_hfs(*argv) || is_ntfs(*argv);
fprintf(stderr, "%s: '%s' is %s%s",
expect == actual ? "ok" : "error",
*argv, actual ? "" : "not ", x);
if (expect != actual)
res = -1;
I think it's a little easier to read with either (a) the dot included
in the 'x' parameter or (b) the entire ".git" missing from the 'x'
parameter.
[...]
> index 56db5c8aba..b2e3cf3f4c 100755
> --- a/t/t0060-path-utils.sh
> +++ b/t/t0060-path-utils.sh
> @@ -468,6 +468,26 @@ test_expect_success 'match .gitmodules' '
> .gitmodules,:\$DATA
> '
>
> +test_expect_success 'match .gitattributes' '
> + test-tool path-utils is_dotgitattributes \
> + .gitattributes \
> + .git${u200c}attributes \
> + .Gitattributes \
> + .gitattributeS \
> + GITATT~1 \
> + GI7D29~1
> +'
> +
> +test_expect_success 'match .gitignore' '
> + test-tool path-utils is_dotgitignore \
> + .gitignore \
> + .git${u200c}ignore \
> + .Gitignore \
> + .gitignorE \
> + GITIGN~1 \
> + GI250A~1
> +'
> +
> test_expect_success MINGW 'is_valid_path() on Windows' '
> test-tool path-utils is_valid_path \
> win32 \
With whatever subset of the changes above makes sense,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks.
next prev parent reply other threads:[~2020-10-05 8:03 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 7:17 [PATCH 0/7] forbidding symlinked .gitattributes and .gitignore Jeff King
2020-10-05 7:19 ` [PATCH 1/7] fsck_tree(): fix shadowed variable Jeff King
2020-10-05 7:44 ` Jonathan Nieder
2020-10-05 8:20 ` Jeff King
2020-10-05 8:29 ` Jonathan Nieder
2020-10-05 7:19 ` [PATCH 2/7] fsck_tree(): wrap some long lines Jeff King
2020-10-05 7:46 ` Jonathan Nieder
2020-10-05 7:19 ` [PATCH 3/7] t7415: rename to expand scope Jeff King
2020-10-05 7:50 ` Jonathan Nieder
2020-10-05 8:24 ` Jeff King
2020-10-05 8:34 ` Jonathan Nieder
2020-10-05 8:49 ` Jeff King
2020-10-05 7:20 ` [PATCH 4/7] t7450: test verify_path() handling of gitmodules Jeff King
2020-10-05 7:53 ` Jonathan Nieder
2020-10-05 8:30 ` Jeff King
2020-10-05 8:38 ` Jonathan Nieder
2020-10-05 7:21 ` [PATCH 5/7] t0060: test obscured .gitattributes and .gitignore matching Jeff King
2020-10-05 8:03 ` Jonathan Nieder [this message]
2020-10-05 8:40 ` Jeff King
2020-10-05 21:20 ` Johannes Schindelin
2020-10-06 14:01 ` Jeff King
2020-10-05 7:24 ` [PATCH 6/7] verify_path(): disallow symlinks in .gitattributes and .gitignore Jeff King
2020-10-05 8:09 ` Jonathan Nieder
2020-10-05 12:07 ` Jeff King
2020-10-05 7:25 ` [PATCH 7/7] fsck: complain when .gitattributes or .gitignore is a symlink Jeff King
2020-10-05 8:12 ` Jonathan Nieder
2020-10-05 8:53 ` Jeff King
2020-10-05 7:32 ` [PATCH 0/7] forbidding symlinked .gitattributes and .gitignore Jonathan Nieder
2020-10-05 8:58 ` Jeff King
2020-10-05 12:16 ` [PATCH v2 0/8] " Jeff King
2020-10-05 12:16 ` [PATCH v2 1/8] fsck_tree(): fix shadowed variable Jeff King
2020-10-05 12:16 ` [PATCH v2 2/8] fsck_tree(): wrap some long lines Jeff King
2020-10-05 12:16 ` [PATCH v2 3/8] t7415: rename to expand scope Jeff King
2020-10-05 12:16 ` [PATCH v2 4/8] t7450: test verify_path() handling of gitmodules Jeff King
2020-10-05 12:16 ` [PATCH v2 5/8] t7450: test .gitmodules symlink matching against obscured names Jeff King
2020-10-05 12:16 ` [PATCH v2 6/8] t0060: test obscured .gitattributes and .gitignore matching Jeff King
2020-10-05 12:16 ` [PATCH v2 7/8] verify_path(): disallow symlinks in .gitattributes and .gitignore Jeff King
2020-10-27 3:35 ` Jonathan Nieder
2020-10-27 7:58 ` Jeff King
2020-10-27 22:00 ` Junio C Hamano
2020-10-28 9:41 ` Jeff King
2020-10-27 23:43 ` Jonathan Nieder
2020-10-28 19:18 ` Junio C Hamano
2020-10-05 12:16 ` [PATCH v2 8/8] fsck: complain when .gitattributes or .gitignore is a symlink Jeff King
2020-10-06 20:41 ` [PATCH v2 0/8] forbidding symlinked .gitattributes and .gitignore Junio C Hamano
2020-10-20 23:19 ` Philip Oakley
2020-10-23 8:17 ` [PATCH] documentation symlink restrictions for .git* files Jeff King
2020-10-23 8:27 ` Jeff King
2020-10-26 22:18 ` Philip Oakley
2020-10-26 22:53 ` Jeff King
2020-10-26 23:32 ` Junio C Hamano
2020-10-27 7:26 ` Jeff King
2020-10-27 18:45 ` Junio C Hamano
2020-10-27 21:00 ` Philip Oakley
2020-10-28 19:14 ` Junio C Hamano
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=20201005080353.GH1166820@google.com \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=peff@peff.net \
/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).