Sven Verdoolaege <skimo@xxxxxxxx> writes:
> 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>
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.
> git-clone.sh | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/git-clone.sh b/git-clone.sh
> index bd44ce1..cdbbc20 100755
> --- a/git-clone.sh
> +++ b/git-clone.sh
> @@ -70,7 +70,8 @@ Perhaps git-update-server-info needs to be run there?"
> git-http-fetch $v -a -w "$tname" "$sha1" "$1" || exit 1
> done <"$clone_tmp/refs"
> rm -fr "$clone_tmp"
> - http_fetch "$1/HEAD" "$GIT_DIR/REMOTE_HEAD" ||
> + http_fetch "$1/HEAD" "$GIT_DIR/REMOTE_HEAD" &&
> + git-http-fetch $v -a $(cat "$GIT_DIR/REMOTE_HEAD") "$1" ||
> rm -f "$GIT_DIR/REMOTE_HEAD"
> }
At this point, "$GIT_DIR/REMOTE_HEAD" is a copy of HEAD obtained
from the remote site via curl. It can contain:
(1) raw SHA-1 of the tip commit, if the HEAD is detached, or
the repository uses a symlink to represent HEAD, or
(2) "ref: refs/heads/$currentbranch".
You would want to do this extra fetch only in case (1).
I think the additional fetch would fail in case (2), and result
in removal of $GIT_DIR/REMOTE_HEAD.
Hmm?
-
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
