Since time immemorial, the test of whether to set "core.filemode" has
been done by trying to toggle the u+x bit on $GIT_DIR/config and then
testing whether the change "took". I find it somewhat odd to use the
config file for this test, but whatever.
The test code didn't set the u+x bit back to its original state
itself, instead relying on the subsequent call to git_config_set() to
re-write the config file with correct permissions.
But ever since
daa22c6f8d config: preserve config file permissions on edits (2014-05-06)
git_config_set() copies the permissions from the old config file to
the new one. This is a good change in and of itself, but it interacts
badly with create_default_files()'s sloppiness, causing "git init" to
leave the executable bit set on $GIT_DIR/config.
So change create_default_files() to reset the permissions on
$GIT_DIR/config after its test.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
builtin/init-db.c | 3 ++-
t/t0001-init.sh | 7 +++++++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 56f85e2..a6d58fd 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -254,7 +254,8 @@ static int create_default_files(const char *template_path)
struct stat st2;
filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
!lstat(path, &st2) &&
- st1.st_mode != st2.st_mode);
+ st1.st_mode != st2.st_mode &&
+ !chmod(path, st1.st_mode));
}
git_config_set("core.filemode", filemode ? "true" : "false");
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index e62c0ff..7de8d85 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -12,6 +12,13 @@ check_config () {
echo "expected a directory $1, a file $1/config and $1/refs"
return 1
fi
+
+ if test_have_prereq POSIXPERM && test -x "$1/config"
+ then
+ echo "$1/config is executable?"
+ return 1
+ fi
+
bare=$(cd "$1" && git config --bool core.bare)
worktree=$(cd "$1" && git config core.worktree) ||
worktree=unset
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
