On Tue, Mar 18, 2014 at 9:27 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > I thought about "GIT_CAPABILITIES= git-upload-pack ..." (and actually > added it in pack-protocol.txt then deleted). The thing is, if you want > to new upload-pack, you would need new git-upload-pack at the remote > end that must understand "git-upload-pack <repo> <caps>" > already. Making it aware about GIT_CAPABILITIES is extra cost for > nothing. And we have to update git-shell to support it eventually. > > Well, the "must understand" part is not entirely true. If you make > git-daemon pass the early capabilities via GIT_CAPABILITIES too, > upload-pack does not have to support "<repo> <caps>" syntax. The > upside is if old git-upload-pack ignores this GIT_CAPABILITIES, it'll > break the protocol (see below) and can print friendly error > messages. git-daemon has no way of printing friendly messages because > it can't negotiate side-band. I should have read my mail one more time before sending. The "git-upload-pack ignores..." sentence is wrong. If it's old, its behavior is fixed and it cannot not send or do anything new. But on the other hand, this is good. The new protocol expects upload-pack to send its caps in a new pkt-line. The old upload-pack does not follow this, which should be the indicator for the client that this server does not support v2, so it could fall back to v1 gracefully. git:// still fails hard because git-daemon is likely old too and rejects it from the beginning. But ssh:// (without git-shell) should work, http:// too. This is a very good point for GIT_CAPABILITIES. -- Duy -- 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