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.)
>
> --
> 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
--
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