[BUG REPORT] "git ls-remote http://git.domain.com/repo.git HEAD" doesn't work

Hi

Following up my recent post, I'm now pretty sure this is a bug. Apparently, ls-remote does not list the HEAD version when used over HTTP(S) whereas it does work otherwise. Check this out:

over HTTP - no HEAD listed here: git ls-remote http://www.kernel.org/pub/scm/git/git.git

over GIT - HEAD is listed in this case: git ls-remote git://github.com/lux/sitellite.git

As Capistrano relies on "git ls-remote http://git.domain.com/repo.git HEAD" to find out which version to pull, you can't deploy from Git over HTTP(S) repos for now. Capistrano is the de facto standard for deploying Ruby on Rails (and related) web applications.

Thanks a lot for looking into this!! (My knowledge unfortunately doesn't allow me to submit a patch myself.)

-sven

On Sat, Jun 14, 2008 at 07:03:36AM +0000, Sven wrote:

$ GIT_CURL_VERBOSE=1 git ls-remote http://www.kernel.org/pub/scm/git/git.git HEAD
* Couldn't find host www.kernel.org in the .netrc file, using defaults
* About to connect() to www.kernel.org port 80 (#0)
*   Trying 204.152.191.37... * Connected to www.kernel.org (204.152.191.37) port 80 (#0)

User-Agent: git/1.5.5.4
Host: www.kernel.org
Accept: */*

< HTTP/1.1 200 OK
< Date: Sat, 14 Jun 2008 07:08:36 GMT
< Server: Apache/2.2.2 (Fedora)
< Last-Modified: Sat, 14 Jun 2008 05:04:30 GMT
< ETag: "14225449-66de-44f9954509380"
< Accept-Ranges: bytes
< Content-Length: 26334
< Content-Type: text/plain; charset=UTF-8
< 
* Expire cleared
* Connection #0 to host www.kernel.org left intact

http://www.kernel.org/pub/scm/git/git.git/info/refs doesn't contain HEAD. Shouldn't it ?

Mike

Mike Hommey <mh@glandium.org> writes:

Traditionally it _never_ talked about HEAD as it technically is not a ref.

Junio C Hamano <gitster <at> pobox.com> writes:

How likely is it that ls-remote HEAD is added for HTTP as well rather than stripped for all protocols?

In the latter case, there's of course a solution for Capistrano like using refs/heads/master as a default instead and allowing the use of other refs by configuration. I could do such a patch, however, this only makes sense of ls-remote HEAD won't be added for HTTP.

-sven

On Sat, Jun 14, 2008 at 07:49:06AM +0000, Sven wrote:

When someone sends a patch ;)

FWIW, quickly looking at the code, it seems the rsync backend may have the same problem. Now, I wonder if other protocols allow to use other refs such as FETCH_HEAD, or if they special case HEAD. I don't have enough time to look this up.

Mike

On Sat, Jun 14, 2008 at 11:02:44AM +0200, Mike Hommey wrote:

I'm not sure I can bring myself to wait for that. After all, it could take nearly negative seven weeks:

  $ git log -1 --pretty=tformat:'%s (%ar)' be885d96
  Make ls-remote http://... list HEAD, like for git://... (7 weeks ago)

-Peff

On Sat, Jun 14, 2008 at 05:19:00AM -0400, Jeff King wrote:

Erf, now I must blame myself to have taken a look at a very old transport.c file ;)

Mike

As I said, I'm lacking the skills. But I'd take part in sponsoring the patch so it's not another 7 weeks wait :-) I know, it's kinda unusual, but it's important to me that Capistrano works out of the box with Git over HTTP. So I'd throw in $50, anybody willing to join, too. Or to do the patch?

-sven

On Sat, Jun 14, 2008 at 09:24:57AM +0000, Sven wrote:

Maybe I wasn't clear in my other message. The wait is either "none, upgrade to the current master", or "a week or so, wait for 1.5.6 to be released."

But I'll take the $50. ;)

Jeff King <peff <at> peff.net> writes:

Oh-kay... guess I'll monkey patch Capistrano and wait till 1.5.6 leaks down to my Gentoo box, shouldn't take long.

Well, hey, offer made. Tell me where to cable it to. Any in any case - thanks for the patch!

-sven

Junio C Hamano <gitster@pobox.com> writes:

Well, to clarify:

 (1) I do not think it is unreasonable to change update-server-info to
     include HEAD in its output.  That would make ls-remote output over
     all protocols consistent;

 (2) However, the client-side tools that run ls-remote may have to
     interact with repositories that are managed with older git (including
     "Today's git").  If they rely on the presense of HEAD, they _are_
     buggy today (and have been so forever), and they _will stay_ buggy
     when they need to access such repositories.

So I do not mind (1) for its "consistency" value, but that would not be a "fix" for your problem.

Also we can do (1) only after somebody audits our own callers to make sure that they do not to get upset by presense of HEAD. They might have been assuming they'd get nothing outside refs/ when talking via http, and suddenly starting to emit HEAD might break them, in which case we cannot afford to do (1) --- that would break older clients.

As Jeff said, he has already done this and it will roll with the upcoming release.

Indeed, there is a way to tell Capistrano to use a specific branch: Adding ...

set :branch, "master"

... to the configuration in deploy.rb does the trick.

-sven

[the usual convention on this list is to cc all participants]

On Sat, Jun 14, 2008 at 06:26:00PM +0000, Sven wrote:

To clarify:

 - I didn't do it, Daniel did. I just used git-log to find it (the
   commit is be885d96).

 - That change has nothing to do with update-server-info, but rather
   happens entirely on the client side. And it appears to just manually
   add HEAD to the fetch list.

-Peff