git-fetch: resolve remote symrefs for HTTP transport

git-fetch validates that a remote ref resolves to a SHA1 prior to calling git-http-fetch. This adds support for resolving a few levels of symrefs to get to the SHA1.

---

Maybe this isn't the right way to handle this - since we're already calling perl we could use LWP to do the transfers (using keepalive even?) or we could let git-http-fetch take care of it and deal with remote names that don't resolve. It may also make sense to modify git-http-fetch so it can fetch more than one head at a time.

 git-fetch.sh |   16 ++++++++++++----
 1 files changed, 12 insertions(+), 4 deletions(-)

aa50f9012834993d8bd080050bc13b23465f9185

index 83143f8..280f62e 100755
@@ -270,14 +270,22 @@ fetch_main () {
 	  if [ -n "$GIT_SSL_NO_VERIFY" ]; then
 	      curl_extra_args="-k"
 	  fi
-	  remote_name_quoted=$(perl -e '
+	  max_depth=5
+	  depth=0
+	  head="ref: $remote_name"
+	  while (expr "z$head" : "zref:" && expr $depth \< $max_depth) >/dev/null
+	  do
+	    remote_name_quoted=$(perl -e '
 	      my $u = $ARGV[0];
+              $u =~ s/^ref:\s*//;
 	      $u =~ s{([^-a-zA-Z0-9/.])}{sprintf"%%%02x",ord($1)}eg;
 	      print "$u";
-	  ' "$remote_name")
-	  head=$(curl -nsfL $curl_extra_args "$remote/$remote_name_quoted") &&
+	  ' "$head")
+	    head=$(curl -nsfL $curl_extra_args "$remote/$remote_name_quoted")
+	    depth=$( expr \( $depth + 1 \) )
+	  done
 	  expr "z$head" : "z$_x40\$" >/dev/null ||
-		  die "Failed to fetch $remote_name from $remote"
+	      die "Failed to fetch $remote_name from $remote"
 	  echo >&2 Fetching "$remote_name from $remote" using http
 	  git-http-fetch -v -a "$head" "$remote/" || exit
 	  ;;

1.3.0.g368f0-dirty

LWP, no. My Mac OS X perl installation appears to have LWP installed by dumb luck but my Gentoo Linux perl doesn't have LWP anywhere in @INC. :-) Yet both systems run GIT happily.

The HTTP support in GIT is already linked against libcurl and libcurl is required to use said HTTP support. I would think that libcurl is capable of using Keep-Alive when possible, and libcurl and C are certainly available anywhere GIT's HTTP support is currently being used. Ideally any HTTP feature should either be using the curl command line tool, or better, be written in C against the libcurl library. But not LWP. Its not always available even though a valid perl is.

Shawn.