On Mon, Apr 25, 2016 at 3:10 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Mon, Apr 25, 2016 at 9:44 AM, David Turner <dturner@xxxxxxxxxxxxxxxx> wrote: >> On Wed, 2016-04-20 at 16:57 -0400, Jeff King wrote: >>> On Wed, Apr 20, 2016 at 04:46:55PM -0400, David Turner wrote: >>> >>> > As you note, it appears that git-daemon does sort-of have support >>> > for >>> > extra args -- see parse_host_arg. So it wouldn't be hard to add >>> > something here. Unfortunately, current versions of git die on >>> > unknown >>> > args. So this change would not be backwards-compatible. We could >>> > put >>> > a decider on it so that clients would only try it when explicitly >>> > enabled. Or we could have clients try it with, and in the event of >>> > an >>> > error, retry without. Neither is ideal, but both are possible. >>> >>> Right. This ends up being the same difficulty that the v2 protocol >>> encountered; how do you figure out what you can speak without >>> resorting >>> to expensive fallbacks, when do you flip the switch, do you remember >>> the >>> protocol you used last time with this server, etc. >> >> Right. >> >> [moved] >>> > If I read this code correctly, git-over-ssh will pass through >>> > arbitrary >>> > arguments. So this should be trivial. >>> >>> It does if you are ssh-ing to a real shell-level account on the >>> server, >>> but if you are using git-shell or some other wrapper to restrict >>> clients >>> from running arbitrary commands, it will likely reject it. >> >> Oh, I see how I was mis-reading shell.c. Oops. >> [/moved] >> >> >>> Which isn't to say it's necessarily a bad thing. Maybe the path >>> forward >>> instead of v2 is to shoe-horn this data into the pre-protocol >>> conversation, and go from there. The protocol accepts that "somehow" >>> it >>> got some extra data from the transport layer, and acts on its >>> uniformly. >> >> OK, so it seems like only HTTP (and non-git-shell-git://) allow backwar >> ds-compatible optional pre-protocol messages. So we don't have good >> options; we only have bad ones. We have to decide which particular >> kind of badness we're willing to accept, and to what degree we care >> about extensibility. As I see it, the badness options are (in no >> particular order): >> >> 1. Nothing changes. >> 2. HTTP grows more extensions; other protocols stagnate. >> 3. HTTP grows extensions; other protocols get extensions but: >> a. only use them on explicit client configuration or >> b. try/fail/remember per-remote >> 4. A backwards-incompatible protocol v2 is introduced, which >> hits alternate endpoints (with the same a/b as above). This is >> different from 3. in that protocol v2 is explicitly designed around >> a capabilities negotiation phase rather than unilateral client-side >> decisions. >> 5. Think of another way to make fetch performant with many refs, and >> defer the extension decision. > > I'd prefer 2,3,4 over 1,5. > > Speaking about 2,3,4: > > Maybe we can do a mix of 2 and 4: > > 1) HTTP grows more extensions; other protocols stagnate for now. > 2) Come up with a backwards-incompatible protocol v2, foccussed on > capabilities negotiation phase, hitting alternative end points > (non http only, or rather a subset of protocols only) > 3) if HTTP sees the benefits of the native protocol v2, we may switch > HTTP, too > > (in time order of execution. Each point is decoupled from the others and may > be done by different people at different times.) > Today I rebased protocol-v2[1] and it was fewer conflicts than expected. I am surprised by myself that there is even a test case for v2 already, so I think it is more progressed that I had in mind. Maybe we can do 1) for now and hope that the non http catches up eventually? [1] https://github.com/stefanbeller/git/tree/protocol-v2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html