[PATCH] git-sh-setup: Fail if the git directory was not found.

[PATCH] git-sh-setup: Fail if the git directory was not found.

[Robert Shearman]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]


Always use git-rev-parse to find a valid git directory, as 
git-repo-config no longer returns an error code if a git directory 
wasn't found.

This fixes the message received when invoking certain commands 
implemented as shell scripts from outside of a git tree, so e.g. instead 
of receiving this:
/home/rob/bin/git-fetch: line 89: /FETCH_HEAD: Permission denied
We get this again:
fatal: Not a git repository: '.git'

Also, move the setting of GIT_OBJECT_DIRECTORY to outside of the 
non-subdir-ok case as it isn't specific to that case.
Signed-off-by: Robert Shearman <rob@codeweavers.com>
---
  git-sh-setup.sh |   12 +++---------
  1 files changed, 3 insertions(+), 9 deletions(-)

Hopefully this patch addresses the concerns of Junio and others by 
continuing to allow git-ls-remotes to work outside of a git repository.

[-- Attachment #2: 268921fd0b2e7ff56c9b455a0129b0e8712fc191.diff --]
[-- Type: text/x-patch, Size: 588 bytes --]

diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index d15747f..49f9e3b 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -37,15 +37,9 @@ esac
 
 if [ -z "$SUBDIRECTORY_OK" ]
 then
-	: ${GIT_DIR=.git}
-	: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
-
-	# Make sure we are in a valid repository of a vintage we understand.
-	GIT_DIR="$GIT_DIR" git repo-config --get core.nosuch >/dev/null
-	if test $? = 128
-	then
-	    exit
-	fi
+	GIT_DIR=$(GIT_DIR=.git git-rev-parse --git-dir) || exit
 else
 	GIT_DIR=$(git-rev-parse --git-dir) || exit
 fi
+
+GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"

Re: [PATCH] git-sh-setup: Fail if the git directory was not found.

[Alex Riesen]

Robert Shearman, Fri, Aug 11, 2006 11:23:30 +0200:
> Always use git-rev-parse to find a valid git directory, as 
> git-repo-config no longer returns an error code if a git directory 
> wasn't found.

BTW, did anyone notice that "--usage" almost always needs git
directory? That is quite unusual.

Re: [PATCH] git-sh-setup: Fail if the git directory was not found.

[Junio C Hamano]

Robert Shearman <rob@codeweavers.com> writes:

> Always use git-rev-parse to find a valid git directory, as
> git-repo-config no longer returns an error code if a git directory
> wasn't found.
>
> This fixes the message received when invoking certain commands
> implemented as shell scripts from outside of a git tree, so
> e.g. instead of receiving this:
> /home/rob/bin/git-fetch: line 89: /FETCH_HEAD: Permission denied
> We get this again:
> fatal: Not a git repository: '.git'
>
> Also, move the setting of GIT_OBJECT_DIRECTORY to outside of the
> non-subdir-ok case as it isn't specific to that case.
>
> Signed-off-by: Robert Shearman <rob@codeweavers.com>

Moving the assignment of GIT_OBJECT_DIRECTORY is fine, but
changing it to an unconditional assignment is wrong.  The user
can have a GIT_OBJECT_DIRECTORY set independently from GIT_DIR
(or ../some/where/.git that is detected).

The rest looks sane; the new test should still detect the case the
original test tried to catch.

>  git-sh-setup.sh |   12 +++---------
>  1 files changed, 3 insertions(+), 9 deletions(-)
>
> Hopefully this patch addresses the concerns of Junio and others by
> continuing to allow git-ls-remotes to work outside of a git repository.
> diff --git a/git-sh-setup.sh b/git-sh-setup.sh
> index d15747f..49f9e3b 100755
> --- a/git-sh-setup.sh
> +++ b/git-sh-setup.sh
> @@ -37,15 +37,9 @@ esac
>  
>  if [ -z "$SUBDIRECTORY_OK" ]
>  then
> -	: ${GIT_DIR=.git}
> -	: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
> -
> -	# Make sure we are in a valid repository of a vintage we understand.
> -	GIT_DIR="$GIT_DIR" git repo-config --get core.nosuch >/dev/null
> -	if test $? = 128
> -	then
> -	    exit
> -	fi
> +	GIT_DIR=$(GIT_DIR=.git git-rev-parse --git-dir) || exit
>  else
>  	GIT_DIR=$(git-rev-parse --git-dir) || exit
>  fi
> +
> +GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"

Re: [PATCH] git-sh-setup: Fail if the git directory was not found.

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Moving the assignment of GIT_OBJECT_DIRECTORY is fine, but
> changing it to an unconditional assignment is wrong.  The user
> can have a GIT_OBJECT_DIRECTORY set independently from GIT_DIR
> (or ../some/where/.git that is detected).

How about this as a replacement?

-- >8 --
[PATCH] git-sh-setup: do not use repo-config to test the git directory

Since repo-config does not fail in non-git directory, it is not
a good command to use to test the git-ness nor validate the
repository revision of $GIT_DIR.

Original patch by Robert Shearman but with minor fixes.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 git-sh-setup.sh |   11 +++--------
 1 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index d15747f..42f9b1c 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -35,17 +35,12 @@ case "$1" in
 	exit
 esac
 
+# Make sure we are in a valid repository of a vintage we understand.
 if [ -z "$SUBDIRECTORY_OK" ]
 then
 	: ${GIT_DIR=.git}
-	: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
-
-	# Make sure we are in a valid repository of a vintage we understand.
-	GIT_DIR="$GIT_DIR" git repo-config --get core.nosuch >/dev/null
-	if test $? = 128
-	then
-	    exit
-	fi
+	GIT_DIR=$(GIT_DIR="$GIT_DIR" git-rev-parse --git-dir) || exit
 else
 	GIT_DIR=$(git-rev-parse --git-dir) || exit
 fi
+: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
-- 
1.4.2.rc4.g9d8df

Re: [PATCH] git-sh-setup: Fail if the git directory was not found.

[Robert Shearman]

Junio C Hamano wrote:

>Junio C Hamano <junkio@cox.net> writes:
>
>  
>
>>Moving the assignment of GIT_OBJECT_DIRECTORY is fine, but
>>changing it to an unconditional assignment is wrong.  The user
>>can have a GIT_OBJECT_DIRECTORY set independently from GIT_DIR
>>(or ../some/where/.git that is detected).
>>    
>>

I'm not an expert in shell scripting so I didn't notice that it was a 
conditional assignment.

>How about this as a replacement?
>  
>

Looks good.

Thanks,

-- 
Rob Shearman