Thomas Rast [off-list ref] writes:
How about trying to read "HEAD" as "head" instead when core.ignorecase
is true? That would allow us to catch such misconfiguration (which I
imagine can also happen accidentally if you mv a repository across FS
boundaries) and tell the user about it.
Do you mean something like this?
I do not like it. It essentially amounts to checking with the FS every
time we run Git.
config.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/config.c b/config.c
index 68d3294..8783937 100644
--- a/config.c
+++ b/config.c
@@ -575,7 +575,16 @@ static int git_default_core_config(const char *var, const char *value)
}
if (!strcmp(var, "core.ignorecase")) {
+ static int true_case; /* 0: unknown, 1: sensitive, 2: fat */
ignore_case = git_config_bool(var, value);
+ if (ignore_case) {
+ if (!true_case) {
+ true_case = fs_is_case_sensitive() ? 1 : 2;
+ if (true_case == 2)
+ warn("Whoa");
+ }
+ ignore_case = true_case >> 1;
+ }
return 0;
}
On Fri, Mar 23, 2012 at 10:47:48AM -0700, Junio C Hamano wrote:
Thomas Rast [off-list ref] writes:
quoted
How about trying to read "HEAD" as "head" instead when core.ignorecase
is true? That would allow us to catch such misconfiguration (which I
imagine can also happen accidentally if you mv a repository across FS
boundaries) and tell the user about it.
Do you mean something like this?
I do not like it. It essentially amounts to checking with the FS every
time we run Git.
I think Thomas's suggestion is to piggy-back it onto an existing file
lookup ("head" instead of "HEAD"), so you aren't doing any extra work.
However, I'm not sure that would be sufficient. If I copy a repo from a
case-insensitive filesystem to a case-sensitive one, what will the case
of "HEAD" be on the new filesystem?
If the original filesystem was case-preserving, I would expect "HEAD".
But on a true caseless filesystem, it could be either. Of course,
current git would already blow up if the file was copied as "head",
which makes me think this is probably a rare case. So maybe that is not
worth worrying about.
I dunno. I think Thomas's idea is clever, but is this actually a problem
in practice? The current discussion seems more like a documentation bug,
and I don't remember seeing anybody reporting issues moving a repo
across filesystems (presumably most people use clone or push, which
handle this properly).
-Peff
On Fri, Mar 23, 2012 at 02:48:44PM -0400, Jeff King wrote:
I think Thomas's suggestion is to piggy-back it onto an existing file
lookup ("head" instead of "HEAD"), so you aren't doing any extra work.
However, I'm not sure that would be sufficient. If I copy a repo from a
case-insensitive filesystem to a case-sensitive one, what will the case
of "HEAD" be on the new filesystem?
If the original filesystem was case-preserving, I would expect "HEAD".
But on a true caseless filesystem, it could be either. Of course,
current git would already blow up if the file was copied as "head",
which makes me think this is probably a rare case. So maybe that is not
worth worrying about.
As soon as I sent this, I had two additional thoughts:
1. You could probably just use "HeAd", which is unlikely to work
anywhere except on a case-insensitive filesystem, and gets around
my objection above.
2. This still isn't a good test, because it is checking case
sensitivity of the repo directory, not the working tree, and
core.ignorecase is about the latter. It's possible to have the two
on different filesystems with different capabilities.
Though I think the initial test in "git init" suffers from the same
problem (it checks that "config" is accessible as "CoNfIg"), and I
have no heard anybody complaining about that.
-Peff