[PATCH] git-fetch: resolve remote symrefs for HTTP transport

[PATCH] git-fetch: resolve remote symrefs for HTTP transport

[Nick Hengeveld]

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.

Signed-off-by: Nick Hengeveld <nickh@reactrix.com>


---

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
diff --git a/git-fetch.sh b/git-fetch.sh
index 83143f8..280f62e 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -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

Re: [PATCH] git-fetch: resolve remote symrefs for HTTP transport

[Shawn Pearce]

Nick Hengeveld <nickh@reactrix.com> wrote:
> 
> 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?)

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.