Re: problem cloning via http since v1.6.6-rc0

On Thu, 21 Jan 2010, Tay Ray Chuan wrote:

khe khe, pardon me, but if git can't talk to its nephew (ie its own repository which was created with earlier version), whenever another nephew (ie git of earlier version) can talk to it, I do consider it to be git's fault ;)

let me zoom in onto difference in communication between two different versions :

*   Trying 217.196.43.134... * Connected to git.debian.org (217.196.43.134) port 80 (#0)

User-Agent: git/1.6.5
Host: git.debian.org
Accept: */*
Pragma: no-cache

< HTTP/1.1 200 OK

whenever, once again, for 1.6.6 it looked much shorter:

*   Trying 217.196.43.134... * Connected to git.debian.org (217.196.43.134) port 80 (#0)

User-Agent: git/1.6.6.267.g5b159
Host: git.debian.org
Accept: */*
Pragma: no-cache

* The requested URL returned error: 404
* Closing connection #0
fatal: http://git.debian.org/git/pkg-exppsy/pymvpa.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?

yes - it is bare... I was 101% sure (isn't that a convention to have .git suffix for directories with bare repositories), but just to make sure:

$> cd /srv/git.debian.org/git/pkg-exppsy/pymvpa.git/
total 76
 8 branches/   8 config   8 description   8 HEAD   8 hooks/   8 info/   8 objects/  12 packed-refs   8 refs/

thanks for info, I did know about this beastie.

I see no references to git-http-backend in apache config -- so indeed should not be the case... but from the git-http-backend description:

,---
| By default, only the `upload-pack` service is enabled, which serves
| 'git-fetch-pack' and 'git-ls-remote' clients, which are invoked from
| 'git-fetch', 'git-pull', and 'git-clone'.
`---

so, it looks like 1.6.6 for some reason decided to assume that it is "smart" http whenever it is not? is that the case here?