On Fri, Aug 25, 2017 at 10:29 AM, Jeff King <peff@xxxxxxxx> wrote: > On Thu, Aug 24, 2017 at 03:53:21PM -0700, Brandon Williams wrote: > >> The biggest question I'm trying to answer is if these are reasonable ways with >> which to communicate a request to a server to use a newer protocol, without >> breaking current servers/clients. As far as I've tested, with patches 1-5 >> applied I can still communicate with current servers without causing any >> problems. > > Current git.git servers, I assume?. How much do we want to care about > alternate implementations? I would not be surprised if other git:// > implementations are more picky about cruft after the virtual-host field > (though I double-checked GitHub's implementation at least, and it is > fine). > > I don't think libgit2 implements the server side. That leaves probably > JGit, Microsoft's VSTS (which I think is custom), and whatever Atlassian > and GitLab use. Before I manually apply the patches to test how they work with Bitbucket Server, are they applied on a branch somewhere where I can just fetch them? If not, I'll apply them manually and verify. Just based on the description, though, I expect no issues. We don't currently support the git:// protocol. Our HTTP handling passes headers through to the receive-pack and upload-pack processes as environment variables (with a little massaging), but doesn't consider them itself; it only considers the URL and "service" query parameter to decide what command to run and to detect "dumb" requests. Our SSH handling ignores any environment variables provided and does not forward them to the git process, similar to VSTS. I'll confirm explicitly, to be certain, but just based on reading the overview and knowing our code I think the described approaches should work fine. Best regards, Bryan Turner
