From: Jeff King <peff@peff.net>
Date: Tue, 18 Mar 2014 04:17:39 GMT
Subject: Re: [PATCH v3 0/8] Hiding refs
Message-ID: <20140318041739.GA7252@sigill.intra.peff.net>
In-Reply-To: <CAJo=hJuGBgkseQ_mvbxFnYbkFDDWEuassf2+ttj_F53AMzU_Nw@mail.gmail.com>

On Fri, Mar 14, 2014 at 05:09:45PM -0700, Shawn Pearce wrote:

> On Fri, Mar 14, 2014 at 4:30 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> > On Fri, Mar 14, 2014 at 11:45 PM, Shawn Pearce <spearce@spearce.org> wrote:
> >>
> >> You missed the SSH case. It doesn't have this slot to hide the data into.
> >
> > Right now we run this for ssh case: "ssh <host> git-upload-pack
> > <repo-path>". New client can do this instead
> >
> > ssh <host> git-upload-pack <repo-path> <client capability flags>
> 
> Older servers will fail on this command, and the client must reconnect
> over SSH, which may mean supplying their password/passphrase again.
> But its remembered that the uploadPack2 didn't work so this can be
> blacklisted and not retried for a while.

I wonder if we could use the environment for optional values. E.g., can
we run:

  ssh host GIT_CAPABILITIES=... git-upload-pack <repo-path>

That will not work everywhere, of course. Sites with git-shell will
fail, as will sites with custom ssh handler (GitHub, for example, and I
imagine Gerrit sites, if they support ssh). So we'd still need some
fallback, but it would work out-of-the-box in a reasonable number of
cases (and it is really not that different than the http case, which is
just stuffing the values into $QUERY_STRING anyway :) ).

-Peff