Re: Request for detailed documentation of git pack protocol

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jun 3, 2009, 15:07 UTC
Message-ID: <20090603150746.GF3355@spearce.org>
In-Reply-To: <20090603144837.GE3355@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> wrote:

Show 5 quoted lines

> Jakub Narebski <jnareb@gmail.com> wrote:
> > What options besides (required?) "host=<server>[:<port>]" are supported?
> 
> Currently only host is supported.  And yea, it takes the :<port> if
> the client included the port number in the URL (git://foo:8813/path).

Ok, I'm wrong.  It *doesn't* send the port.  The reason is obtuse,
but git_tcp_connect() clobbers the port number out of the host
name string, so that later when git_connect() sends this "host=%s",
only the host name is transmitted.

> Actually, I just realized JGit isn't compliant here.  It doesn't
> send the :<port> like C Git would.

So, actually JGit is compliant here.

> > Do I understand correctly that "host=<host>" information is required
> > for core.gitProxy to work, isn't it?

If core.gitProxy or GIT_PROXY_COMMAND are set, you can lie to the remote git daemon about the host. E.g.:

  $ cat proxy.sh
  #!/bin/sh
  exec nc git.kernel.org 9418

  GIT_PROXY_COMMAND=proxy.sh git ls-remote git://github.com/foo.git

During that kernel.org receives "\0host=github.com\0" host header, which is not the name you connected to it as. :-)

In practice I doubt anyone would do that, but, you can confuse yourself. I guess about equally as well as url.insteadof. :-)

-- 
Shawn.