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

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

[Sven]

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

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

[Mike Hommey]

On Sat, Jun 14, 2008 at 07:03:36AM +0000, Sven wrote:
> 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.)

$ 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)
> GET /pub/scm/git/git.git/info/refs HTTP/1.1
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

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

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

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

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

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

[Sven]

Junio C Hamano <gitster <at> pobox.com> writes:
> Traditionally it _never_ talked about HEAD as it technically is not a ref.

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

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

[Mike Hommey]

On Sat, Jun 14, 2008 at 07:49:06AM +0000, Sven wrote:
> Junio C Hamano <gitster <at> pobox.com> writes:
> > Traditionally it _never_ talked about HEAD as it technically is not a ref.
> 
> How likely is it that ls-remote HEAD is added for HTTP as well rather than
> stripped for all protocols?

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

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

[Jeff King]

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

> > How likely is it that ls-remote HEAD is added for HTTP as well rather than
> > stripped for all protocols?
> 
> When someone sends a patch ;)

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

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

[Sven]

> When someone sends a patch ;)

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

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

[Mike Hommey]

On Sat, Jun 14, 2008 at 05:19:00AM -0400, Jeff King wrote:
> On Sat, Jun 14, 2008 at 11:02:44AM +0200, Mike Hommey wrote:
> 
> > > How likely is it that ls-remote HEAD is added for HTTP as well rather than
> > > stripped for all protocols?
> > 
> > When someone sends a patch ;)
> 
> 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)

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

Mike

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

[Jeff King]

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

> 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?

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. ;)

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

[Sven]

Jeff King <peff <at> peff.net> writes:
> 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."

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

> But I'll take the $50. ;)

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

-sven

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

[Junio C Hamano]

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

> Mike Hommey <mh@glandium.org> writes:
>
>> http://www.kernel.org/pub/scm/git/git.git/info/refs doesn't contain HEAD.
>> Shouldn't it ?
>
> Traditionally it _never_ talked about HEAD...

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.

Re: [BUG REPORT]

[Sven]

>  (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;

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

>  (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.

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

Re: [BUG REPORT]

[Jeff King]

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

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

> >  (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;
> 
> As Jeff said, he has already done this and it will roll with the 
> upcoming release.

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