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

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

[Sascha Cunz]

>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

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

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

[Junio C Hamano]

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, 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.

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

[Sascha Cunz]

On Friday, July 27, 2012 02:55:49 PM you wrote:
> 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.

> 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.

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

[Junio C Hamano]

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.

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

[Sascha Cunz]

On Friday, July 27, 2012 03:58:49 PM you wrote:
> 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 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.