[PATCH] git-clone.sh: properly configure remote even if remote's head is dangling

[PATCH] git-clone.sh: properly configure remote even if remote's head is dangling

[Gerrit Pape]

When cloning a remote repository which's HEAD refers to a nonexistent
ref, git-clone cloned all existing refs, but failed to write the
configuration for 'remote'.  Now it detects the dangling remote HEAD,
refuses to checkout any local branch since HEAD refers to nowhere, but
properly writes the configuration for 'remote', so that subsequent
'git fetch's don't fail.

The problem was reported by Daniel Jacobowitz through
 http://bugs.debian.org/466581

Signed-off-by: Gerrit Pape <pape@smarden.org>
---
 git-clone.sh           |   18 +++++++++++++-----
 t/t5701-clone-local.sh |    8 ++++++++
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/git-clone.sh b/git-clone.sh
index b4e858c..0d686c3 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -409,11 +409,12 @@ else
 	cd "$D" || exit
 fi
 
-if test -z "$bare" && test -f "$GIT_DIR/REMOTE_HEAD"
+if test -z "$bare"
 then
 	# a non-bare repository is always in separate-remote layout
 	remote_top="refs/remotes/$origin"
-	head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
+	head_sha1=
+	test ! -r "$GIT_DIR/REMOTE_HEAD" || head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
 	case "$head_sha1" in
 	'ref: refs/'*)
 		# Uh-oh, the remote told us (http transport done against
@@ -470,9 +471,16 @@ then
 		git config branch."$head_points_at".merge "refs/heads/$head_points_at"
 		;;
 	'')
-		# Source had detached HEAD pointing nowhere
-		git update-ref --no-deref HEAD "$head_sha1" &&
-		rm -f "refs/remotes/$origin/HEAD"
+		if test -z "$head_sha1"
+		then
+			# Source had nonexistent ref in HEAD
+			echo >&2 "Warning: Remote HEAD refers to nonexistent ref, unable to checkout."
+			no_checkout=t
+		else
+			# Source had detached HEAD pointing nowhere
+			git update-ref --no-deref HEAD "$head_sha1" &&
+			rm -f "refs/remotes/$origin/HEAD"
+		fi
 		;;
 	esac
 
diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh
index 822ac8c..59a165a 100755
--- a/t/t5701-clone-local.sh
+++ b/t/t5701-clone-local.sh
@@ -63,4 +63,12 @@ test_expect_success 'Even without -l, local will make a hardlink' '
 	test 0 = $copied
 '
 
+test_expect_success 'local clone of repo with nonexistent ref in HEAD' '
+	cd "$D" &&
+	echo "ref: refs/heads/nonexistent" > a.git/HEAD &&
+	git clone a d &&
+	cd d &&
+	git fetch &&
+	test ! -e .git/refs/remotes/origin/HEAD'
+
 test_done
-- 
1.5.4.2

Re: [PATCH] git-clone.sh: properly configure remote even if remote's head is dangling

[Johannes Schindelin]

Hi,

On Wed, 20 Feb 2008, Gerrit Pape wrote:

> When cloning a remote repository which's HEAD refers to a nonexistent 
> ref, git-clone cloned all existing refs, but failed to write the 
> configuration for 'remote'.  Now it detects the dangling remote HEAD, 
> refuses to checkout any local branch since HEAD refers to nowhere, but 
> properly writes the configuration for 'remote', so that subsequent 'git 
> fetch's don't fail.

I like your reasoning, and your patch.  Except maybe...

> diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh
> index 822ac8c..59a165a 100755
> --- a/t/t5701-clone-local.sh
> +++ b/t/t5701-clone-local.sh
> @@ -63,4 +63,12 @@ test_expect_success 'Even without -l, local will make a hardlink' '
>  	test 0 = $copied
>  '
>  
> +test_expect_success 'local clone of repo with nonexistent ref in HEAD' '
> +	cd "$D" &&

... making this a subshell would be nice, so that subsequent tests start 
out from trash/ again?

Ciao,
Dscho

Re: [PATCH] git-clone.sh: properly configure remote even if remote's head is dangling

[Junio C Hamano]

Gerrit Pape <pape@smarden.org> writes:

> When cloning a remote repository which's HEAD refers to a nonexistent
> ref, git-clone cloned all existing refs, but failed to write the
> configuration for 'remote'.  Now it detects the dangling remote HEAD,
> refuses to checkout any local branch since HEAD refers to nowhere, but
> properly writes the configuration for 'remote', so that subsequent
> 'git fetch's don't fail.

The patch looks Ok, thanks.

By the way, I am still waiting for an ack/nack to my butchering
of your earlier "hash-object" patch.

  http://thread.gmane.org/gmane.comp.version-control.git/73811/focus=73964
  Message-Id: <7vskzugm8x.fsf@gitster.siamese.dyndns.org>