> Does the code behave sensibly when the --server-option=... option is > given and > > (a) the given option is not understood by the other side that talks > protocol v2? Or > > (b) it turns out that the other side does not talk protocol v2? > > In the former case, I would expect that there would be a way to > respond with a failure for the other side and "git clone" should > notice and respond by die()-ing at the end. Right now, the server ignores it (it collects them as "keys" in process_request() in serve.c and then passes them to the individual commands, but they don't do anything about it). Right now it's documented as: -o <option>:: --server-option=<option>:: Transmit the given string to the server when communicating using protocol version 2. The given string must not contain a NUL or LF character. When multiple `--server-option=<option>` are given, they are all sent to the other side in the order listed on the command line. I'm inclined to add: The server's handling of server options, including unknown ones, is server-specific. > In the latter case, I would expect at least that a warning about > accepted but ignored server-option to be given, or "git clone" to > fail with an error "cannot honor the server-option". Right now there's no warning, but I'll add one in the next reroll to both "fetch" and "clone". > If the code does not match the above expectations, at least that > should be documented, I think. If "git fetch" shares the same > issue, this would be a good time to address it, too.
