On Tue, 2016-04-19 at 21:17 -0400, Jeff King wrote: > On Tue, Apr 19, 2016 at 07:43:11PM -0400, David Turner wrote: > > > On Tue, 2016-04-19 at 19:22 -0400, Jeff King wrote: > > > You can find previous discussion on the list, but I think the > > > options > > > basically are: > > > > > > 1. Something like v2, where the client gets a chance to speak > > > before > > > the advertisement. > > > > > > 2. Some out-of-band way of getting values from the client to > > > the > > > server (so maybe extra command-line arguments for git-over > > > -ssh, > > > and > > > maybe shoving something after the "\0" for git-daemon, and > > > of > > > course extra parameters for HTTP). > > > > > > 3. The client saying "stop spewing refs at me, I want to give > > > you a > > > ref filter" asynchronously, and accepting a little spew at > > > the > > > beginning of each conversation. That obviously only works > > > for > > > the > > > full-duplex transports, so you'd probably fall back to (2) > > > for > > > http. > > > > OK, so (2) seems like what I'm doing -- it just happens that I only > > implemented it for one protocol. > > Right. And I don't mind that approach _if_ we can figure out a way to > do > it for all protocols. But I think there are some complications with > the > other ones, which means that HTTP will have the ability to grow > features > the other protocols do not.
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. If I read this code correctly, git-over-ssh will pass through arbitrary arguments. So this should be trivial. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
