Usman Akinyemi <usmanakinyemi202@xxxxxxxxx> writes: > Let's introduce a new configuration option, `osversion.command`, to handle > the string exchange between servers and clients. This option allows > customization of the exchanged string by leveraging the output of the > specified command. This customization might be especially useful on some > quite uncommon platforms like NonStop where interesting OS information is > available from other means than uname(2). After reading the above rationale, I doubt the usefulness of this feature even more. Shouldn't that kind of anomalies be handled by compat/ layer to make their uname(2) emulated, or allow get_uname_info() to be customized at compile time by platform implementations, to yield more useful pieces of information instead? That way, we do not need to add another mechanism that lets people spawn an arbitrary command while Git is running, we do not need to worry about security implications, and we do not need to worry about people abusing the facility to throw totally random and useless garbage information at the other end to make their stats useless. I'll skip the overly wide documentation changes. > diff --git a/Documentation/config/transfer.txt b/Documentation/config/transfer.txt > ... > diff --git a/Documentation/gitprotocol-v2.txt b/Documentation/gitprotocol-v2.txt > ... > +test_expect_success 'test capability advertisement with osVersion.command config set' ' > + test_config osVersion.command "uname -srvm" && If osversion.command configuration variable turns out to be acceptable addition, I do not think we want to use "uname -srvm" as its value for its test. Do you know for sure how portable srvm is? If you use something like "printf ' \001a\011b\015\012c '", you do not even have to worry about how portable srvm is and on top, you can test your unprintable-redacting logic in the code. But all of that may be moot, if we take the "fewer customization at runtime" approach. Thanks.
