From: Michael Haggerty <mhagger@alum.mit.edu>
To: git@vger.kernel.org
Cc: gitster@pobox.com, Michael Haggerty <mhagger@alum.mit.edu>
Subject: [RFC 4/6] git-check-attr: Normalize paths
Date: Thu, 28 Jul 2011 12:37:03 +0200 [thread overview]
Message-ID: <1311849425-9057-5-git-send-email-mhagger@alum.mit.edu> (raw)
In-Reply-To: <1311849425-9057-1-git-send-email-mhagger@alum.mit.edu>
Normalize the path arguments (relative to the working tree root, if
applicable) before looking up their attributes. This requires passing
the prefix down the call chain.
This fixes two test cases for different reasons:
* "unnormalized paths" is fixed because the .gitattribute-file-seeking
code is not confused into reading the top-level file twice.
* "relative paths" is fixed because the canonical pathnames are passed
to get_checkattr() or get_allattrs(), allowing them to match the
pathname patterns as expected.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
I had a very hard time figuring out the correct approach to fixing
this problem. There is so little documentation in the C code! The
suggested patch fixes the tests, but it might be wrong for other
reasons:
1. I'm not sure whether it is correct to fix this problem at the level
of git-check-attr, or whether the fix belongs in the API layer.
What is the convention for API functions? Do they typically take
path names relative to the CWD or relative to the working tree
root, or ...? I also found examples of commands that change the
current directory during their operation, making the CWD and the
working tree root identical. What is preferred? (And where is it
documented?)
2. It could be that I'm abusing the prefix_path() function, or that
there is a better way to achieve the normalization.
builtin/check-attr.c | 20 ++++++++++++--------
t/t0003-attributes.sh | 4 ++--
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/builtin/check-attr.c b/builtin/check-attr.c
index 781b7df..23a6e07 100644
--- a/builtin/check-attr.c
+++ b/builtin/check-attr.c
@@ -41,22 +41,26 @@ static void output_attr(int cnt, struct git_attr_value *check,
}
}
-static void check_attr(int cnt, struct git_attr_value *check,
- const char *file)
+static void check_attr(const char *prefix, int cnt,
+ struct git_attr_value *check, const char *file)
{
+ const char *full_path =
+ prefix_path(prefix, prefix ? strlen(prefix) : 0, file);
if (check != NULL) {
- if (git_checkattr(file, cnt, check))
+ if (git_checkattr(full_path, cnt, check))
die("git_checkattr died");
output_attr(cnt, check, file);
} else {
- if (git_allattrs(file, &cnt, &check))
+ if (git_allattrs(full_path, &cnt, &check))
die("git_allattrs died");
output_attr(cnt, check, file);
free(check);
}
+ free(full_path);
}
-static void check_attr_stdin_paths(int cnt, struct git_attr_value *check)
+static void check_attr_stdin_paths(const char *prefix, int cnt,
+ struct git_attr_value *check)
{
struct strbuf buf, nbuf;
int line_termination = null_term_line ? 0 : '\n';
@@ -70,7 +74,7 @@ static void check_attr_stdin_paths(int cnt, struct git_attr_value *check)
die("line is badly quoted");
strbuf_swap(&buf, &nbuf);
}
- check_attr(cnt, check, buf.buf);
+ check_attr(prefix, cnt, check, buf.buf);
maybe_flush_or_die(stdout, "attribute to stdout");
}
strbuf_release(&buf);
@@ -154,10 +158,10 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
}
if (stdin_paths)
- check_attr_stdin_paths(cnt, check);
+ check_attr_stdin_paths(prefix, cnt, check);
else {
for (i = filei; i < argc; i++)
- check_attr(cnt, check, argv[i]);
+ check_attr(prefix, cnt, check, argv[i]);
maybe_flush_or_die(stdout, "attribute to stdout");
}
return 0;
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index f6cf77d..ae2f1da 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -93,7 +93,7 @@ test_expect_success 'attribute test' '
'
-test_expect_failure 'unnormalized paths' '
+test_expect_success 'unnormalized paths' '
attr_check ./f f &&
attr_check ./a/g a/g &&
@@ -102,7 +102,7 @@ test_expect_failure 'unnormalized paths' '
'
-test_expect_failure 'relative paths' '
+test_expect_success 'relative paths' '
(cd a && attr_check ../f f) &&
(cd a && attr_check f f) &&
--
1.7.6.8.gd2879
next prev parent reply other threads:[~2011-07-28 10:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-28 10:36 [RFC 0/6] git-check-attr should work for relative paths Michael Haggerty
2011-07-28 10:37 ` [RFC 1/6] git-check-attr: test that no output is written to stderr Michael Haggerty
2011-07-28 10:37 ` [RFC 2/6] git-check-attr: Demonstrate problems with unnormalized paths Michael Haggerty
2011-07-28 10:37 ` [RFC 3/6] git-check-attr: Demonstrate problems with relative paths Michael Haggerty
2011-07-28 10:37 ` Michael Haggerty [this message]
2011-08-02 17:24 ` [RFC 4/6] git-check-attr: Normalize paths Junio C Hamano
2011-08-04 3:32 ` Michael Haggerty
2011-08-04 17:05 ` Junio C Hamano
2011-08-05 6:24 ` Michael Haggerty
2011-08-05 15:02 ` Junio C Hamano
2011-08-07 4:32 ` Michael Haggerty
2011-07-28 10:37 ` [RFC 5/6] test-path-utils: Add subcommand "absolute_path" Michael Haggerty
2011-07-28 10:37 ` [RFC 6/6] test-path-utils: Add subcommand "prefix_path" Michael Haggerty
2011-08-02 22:02 ` [RFC 0/6] git-check-attr should work for relative paths Junio C Hamano
2011-08-04 3:35 ` Michael Haggerty
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=1311849425-9057-5-git-send-email-mhagger@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.