git-clone supports cloning from a repo with detached HEAD, but if this HEAD is not behind any branch tip then it would not have been fetched over dumb http, resulting in a fatal: Not a valid object name HEAD Since 928c210a, this would also happen on a http repo with a HEAD that is a symbolic link where someone has forgotton to run update-server-info. Signed-off-by: Sven Verdoolaege <skimo@xxxxxxxx> --- On Thu, Jun 28, 2007 at 05:02:18PM -0700, Junio C Hamano wrote: > Ok. But I think the change regresses when the remote side is > actually on a particular branch, and is using symref to > represent $GIT_DIR/HEAD. Updated patch tested on both symbolic links and symrefs. skimo git-clone.sh | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/git-clone.sh b/git-clone.sh index bd44ce1..4cbf60f 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -72,6 +72,17 @@ Perhaps git-update-server-info needs to be run there?" rm -fr "$clone_tmp" http_fetch "$1/HEAD" "$GIT_DIR/REMOTE_HEAD" || rm -f "$GIT_DIR/REMOTE_HEAD" + if test -f "$GIT_DIR/REMOTE_HEAD"; then + head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"` + case "$head_sha1" in + 'ref: refs/'*) + ;; + *) + git-http-fetch $v -a "$head_sha1" "$1" || + rm -f "$GIT_DIR/REMOTE_HEAD" + ;; + esac + fi } quiet= -- 1.5.2.2.585.g9cc0-dirty - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
