On Fri, Apr 29, 2016 at 4:05 PM, David Turner <dturner@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2016-04-26 at 20:59 -0700, Stefan Beller wrote: >> 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 > > > Do you plan to send these patches to the mailing list? What's the next > step here? I can send them out if you want to. As I flip flop between "they are perfect" and "they are horrible, nobody should see them", I haven't done it so far (also time constraints). Will send them later today, in case it's urgent you can fetch them from my github account. What's the next step? I don't know. I guess we can either collaborate on a large series (do-it-all) or rather work on many smaller series' that solve it partially one by one. I'll send the patches out later today. Thanks, Stefan -- 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