Jon Loeliger <jdl@xxxxxxxxxxxxx> writes: > If possible, I'd like to consider my (Linus') notion > of the extension to the git protocol supplying the client > hostname as part of a "standard" release like 1.4.0. I think the virtual hosting of git-daemon is very important, and I do not want to have a half-baked one hurriedly cobbled together for 1.4.0 on the server side. > We don't necessarily have to agree on how it is used yet, > but if we can get the protocol enhancement into this > release, I think it would make for a good "flag day" > sort of change. I do agree it is a good idea to have the client-side support in 1.4.0; that would work well with the current git-daemon. Since the extension is backward compatible, we can tell the users to use 1.4.0 or later clients when the daemon side is done. That is much nicer than telling them to use what's on "master" that is later than such-and-such commit. > Specifically, I'd like to consider the portion my patch > that passes "\0HOST=%s\0" along with the git: protocol > connection. > > Any chance for that? If you'd like, I work on resubmitting > just those bits with the connect function refactoring > that you outlined. I appreciate the offer very much. Although I said port is something the server side can usually tell, I would throw in port there as well. Maybe there is some port forwarding (or reverse NAPT) involved in the path from the client to the server. Any reason to spell HOST in all uppercase by the way? And thanks for reminding me. The list of things-to-have in the message was based on a week old "What's in", and I was about to compose a message describing what I did not talk about in it, because I wanted to say something about virtual hosting of git-daemon. - : 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