threads / rfc / 31118

RFC patchUse work tree to determine if it supports symlinks

Subject: [RFC/PATCH] Use work tree to determine if it supports symlinks

## tl;dr

5 messages between Jul 27, 2012 and Jul 27, 2012. Diffs are folded; open one to read it.

replies: 4people: 3as markdown or json

Sascha Cunz· Jul 27, 2012, 21:39 UTC · lore
>From 3f449e719b924929f1f8ca9b5eff83f17bc64c60 Mon Sep 17 00:00:00 2001
From: Sascha Cunz <Sascha@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 <Sascha@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
Show changes to builtin/init-db.c +17 −5
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, "tXXXXXX");
@@ -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
Junio C Hamano· Jul 27, 2012, 21:55 UTC · re: Sascha Cunz · lore

Re: [RFC/PATCH] Use work tree to determine if it supports symlinks

Sascha Cunz <Sascha-ML@babbelbox.org> writes:
Show 11 quoted lines
> From 3f449e719b924929f1f8ca9b5eff83f17bc64c60 Mon Sep 17 00:00:00 2001
> From: Sascha Cunz <Sascha@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.

Sascha Cunz· Jul 27, 2012, 22:40 UTC · re: Junio C Hamano · lore

Re: [RFC/PATCH] Use work tree to determine if it supports symlinks

On Friday, July 27, 2012 02:55:49 PM you wrote:
Show 16 quoted lines
> Sascha Cunz <Sascha-ML@babbelbox.org> writes:
> > From 3f449e719b924929f1f8ca9b5eff83f17bc64c60 Mon Sep 17 00:00:00 2001
> > From: Sascha Cunz <Sascha@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.
Show 5 quoted lines
> 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.

Junio C Hamano· Jul 27, 2012, 22:58 UTC · re: Sascha Cunz · lore

Re: [RFC/PATCH] Use work tree to determine if it supports symlinks

Sascha Cunz <Sascha@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.

Sascha Cunz· Jul 27, 2012, 23:51 UTC · re: Junio C Hamano · lore

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 <Sascha@babbelbox.org> writes:
Show 5 quoted lines
> > 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.

← back to recent threads