[RFC/PATCH] Use work tree to determine if it supports symlinks
From 3f449e719b924929f1f8ca9b5eff83f17bc64c60 Mon Sep 17 00:00:00 2001
From: Sascha Cunz sas...@babbelbox.org
Date: Fri, 27 Jul 2012 22:54:56 +0200
Subject: [PATCH] Use work tree to determine if it supports symlinks
When creating a new repository, we check some capabilities of the
underlying file system(s). We check the file system for its case
sensitivity and the ability to create symbolic links.
Before this patch the .git-dir was used for this check, while the
comments in code clearly state to test on the work tree.
This patch teaches the tests for symbolic links and utf8 precomposion
to use the work tree instead of the .git directory.
Signed-off-by: Sascha Cunz sas...@babbelbox.org
---
builtin/init-db.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
In recent discussion[1] on libgit2, we found this little inconsistency
and it's not exactly clear, whether the git implementation or documentation
should be followed.
I left out to change the case-insensitive check. If you think, this patch
is useful at all (I actually have a hard time to find a real world use
case), i would reroll it with that change included. I think in this case,
the probe_utf8_pathname_composition might be refactored: We don't have a
file in the work tree yet = we must create one, test its accessibility
with a different name and finally unlink it. That's more or less what
probe_utf8_pathname_composition does.
SaCu
[1] https://github.com/libgit2/libgit2/pull/844#issuecomment-7311677
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 244fb7f..2f988ad 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -273,6 +273,23 @@ static int create_default_files(const char *template_path)
}
if (!reinit) {
+ const char *work_tree = get_git_work_tree();
+
+ /* Check if the filesystem is case-insensitive */
+ path[len] = 0;
+ strcpy(path + len, CoNfIg);
+ if (!access(path, F_OK))
+ git_config_set(core.ignorecase, true);
+
+ /* Point 'path' to the work tree */
+ len = strlen(work_tree);
+ if (len sizeof(path)-8)
+ die(_(insane working directory %s), work_tree);
+
+ memcpy(path, work_tree, len);
+ if (len path[len-1] != '/')
+ path[len++] = '/';
+
/* Check if symlink is supported in the work tree */
path[len] = 0;
strcpy(path + len, tXX);
@@ -285,11 +302,6 @@ static int create_default_files(const char *template_path)
else
git_config_set(core.symlinks, false);
- /* Check if the filesystem is case-insensitive */
- path[len] = 0;
- strcpy(path + len, CoNfIg);
- if (!access(path, F_OK))
- git_config_set(core.ignorecase, true);
probe_utf8_pathname_composition(path, len);
}
--
1.7.12.rc0.23.g3f449e7
--
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
Re: [RFC/PATCH] Use work tree to determine if it supports symlinks
Sascha Cunz sascha...@babbelbox.org writes: From 3f449e719b924929f1f8ca9b5eff83f17bc64c60 Mon Sep 17 00:00:00 2001 From: Sascha Cunz sas...@babbelbox.org Date: Fri, 27 Jul 2012 22:54:56 +0200 Subject: [PATCH] Use work tree to determine if it supports symlinks When creating a new repository, we check some capabilities of the underlying file system(s). We check the file system for its case sensitivity and the ability to create symbolic links. Before this patch the .git-dir was used for this check, while the comments in code clearly state to test on the work tree. That is simply because a layout that has .git and its containing directory (i.e. the working tree) on a separate filesystem when we run git init is not supported, and more importantly, we do not want to step outside .git, which is the simplest and safest way to avoid touching the end-user data that sits in the working tree. The code comment is about checking the filesystem that houses both the working tree and .git; if the user later wants to turn .git into a separate mount point, or if the user wants to use GIT_DIR and GIT_WORK_TREE to create a funny layout, the user should know how to muck with .git/config to adjust to the peculiarity. -- 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
Re: [RFC/PATCH] Use work tree to determine if it supports symlinks
On Friday, July 27, 2012 02:55:49 PM you wrote: Sascha Cunz sascha...@babbelbox.org writes: From 3f449e719b924929f1f8ca9b5eff83f17bc64c60 Mon Sep 17 00:00:00 2001 From: Sascha Cunz sas...@babbelbox.org Date: Fri, 27 Jul 2012 22:54:56 +0200 Subject: [PATCH] Use work tree to determine if it supports symlinks When creating a new repository, we check some capabilities of the underlying file system(s). We check the file system for its case sensitivity and the ability to create symbolic links. Before this patch the .git-dir was used for this check, while the comments in code clearly state to test on the work tree. That is simply because a layout that has .git and its containing directory (i.e. the working tree) on a separate filesystem when we run git init is not supported, But isn't enforced either. Are there known issues? and more importantly, we do not want to step outside .git, which is the simplest and safest way to avoid touching the end-user data that sits in the working tree. While I think that this is true, I don't see the connection. The code comment is about checking the filesystem that houses both the working tree and .git; if the user later wants to turn .git into a separate mount point, or if the user wants to use GIT_DIR and GIT_WORK_TREE to create a funny layout, the user should know how to muck with .git/config to adjust to the peculiarity. Ok, so repository and working directory are simply not meant to be on different file systems. Thanks for the clarification. -- 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
Re: [RFC/PATCH] Use work tree to determine if it supports symlinks
Sascha Cunz sas...@babbelbox.org writes: Ok, so repository and working directory are simply not meant to be on different file systems. Thanks for the clarification. I did not mean and that is a rule we need to enforce and keep forever. I was just answering your (implied) question why does code comment, behaviour and documentation disagree?, to give a data point that would be useful when discussing what the ideal behaviour should be. -- 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
Re: [RFC/PATCH] Use work tree to determine if it supports symlinks
On Friday, July 27, 2012 03:58:49 PM you wrote: Sascha Cunz sas...@babbelbox.org writes: Ok, so repository and working directory are simply not meant to be on different file systems. Thanks for the clarification. I did not mean and that is a rule we need to enforce and keep forever. I did not parse your statement as such - I just realized, that i probably won't find a valid use case for using 2 file systems with different capabilities. Which lead me to conclude that your is not supported is a sufficient response. Though, I think I have a valid use case for using different file systems: For speed reasons one could setup .git to point to a different drive. I wanted to try this ever since I saw, it would be possible - but I never came around actually trying it. However, if this would turn out to be an improvement, I don't think one would mix file systems with different capabilities (i.e. FAT+ext2). I was just answering your (implied) question why does code comment, behaviour and documentation disagree?, to give a data point that would be useful when discussing what the ideal behaviour should be. I think, that 'git init --separate-git-dir' (without a 'different filesystems' restriction) is some kind of support for creating non-bare repositories where work tree and .git dir are located on different file systems. Then, in case a user _did_ setup a peculiar layout, an invocation of 'git submodule init' might make a call to 'git clone', which _should_ set core.symlinks to false but doesn't. At that point the user might not remember in detail how peculiar the setup actually is - and at the same time did not request git to do anything special. I don't know how far-fetched that is, but it's at least possible. -- 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
