Subject: RE: [PATCH v2 6/6] version: introduce osversion.command config for os-version output

From: <[email-masked]>
Date: Tue, 21 Jan 2025 14:51:14 -0500

On January 21, 2025 2:14 PM, Junio C Hamano wrote:
>Usman Akinyemi <[email-masked]> writes:
>
>>> 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.
>>
>> 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.
>
>It only tells us that uname(2) gives useless information on the platform,
but there
>are other ways to ask the system for more useful information.  Isn't that
the same
>deal with how useful information is obtained from not uname(2), since a
useful one
>does not exist there, but from GetVersion() on mingw?  We do not have to
spawn
>an external process on MinGW to do this---we shouldn't have to do so on
NonStop,
>either.  We should be able to make a call into a NonStop specific code you
or Randal
>add in compat/ from get_uname_info() to hide the platform-specific details,
no?

I agree. One this series is finalized, I can put together a patch to obtain
OS details
on NonStop from proprietary calls. Not something I am happy about doing, but
it is what it is. I still do not get why people cannot just run 'uname -a'
instead of
this integration. From a support standpoint, knowing what OS level was used
in
the build is more useful that git telling me what I can get from uname. But
I
accept that others want this, so I'm going with it - once the code is
accepted
into base git.