On Sat, Jan 18, 2025 at 4:03 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. Hi Junio, Thanks for the review. This config option was added at Randall's request. Randall wrote: "Instead of an override, what about a knob that specifies the uname command to use to build the value. Personally, I would use `uname -s -r -v` on NonStop to get the kernel version used in the build. The difficulty on my platform is that this is not truly useful info. The effective build OS compatibility version is in a #define __L_Series_RVU and __H_Series_RVU, so the knob might be needed in git_compat_util.h or similar. This comes from the compiler arguments, which are not yet captured." So, the difficulty is that the compile time information might not be useful. This patch is the last patch of the series and can be a stand alone also. Thank you. > > 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.
