Re: [PATCH v3 0/8] Hiding refs

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 14, 2014, 12:37 UTC
Message-ID: <CACsJy8AZ0CfqHRYDrnQD+z0ibVQnsFuSzktEHKRhCVwaXPQryg@mail.gmail.com>
In-Reply-To: <20140311203650.GA31173@sigill.intra.peff.net>

On Wed, Mar 12, 2014 at 3:36 AM, Jeff King <peff@peff.net> wrote:

Show 10 quoted lines

> If the client is limited to setting a few flags, then something like
> http can get away with:
>
>   GET foo.git/info/refs?service=git-upload-pack&advertise-symrefs&refspec=refs/heads/*
>
> And it does not need to worry about upload-pack2 at all. Either the
> server recognizes and acts on them, or it ignores them.
>
> But given that we do not have such a magic out-of-band method for
> passing values over ssh and git, maybe it is not worth worrying about.

git could go the same if we lift the restriction in 73bb33a (daemon: Strictly parse the "extra arg" part of the command - 2009-06-04). It's been five years. Old daemons hopefully have all died out by now. For ssh, I suppose upload-pack and receive-pack can take an extra argument like "advertise-symrefs&refspec=refs/heads/*" (daemon would use it too to pass the advertiment to upload-pack and receive-pack).

That would make all three not need to change the underlying protocol for capability advertisement. Old git-daemon, upload-pack and receive-pack will fail hard on the new advertisement though, unlike http. But that's no worse than upload-pack2.

> Http can move to upload-pack2 along with the rest.

Or maybe http may lead the rest to another way.

-- 
Duy