Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]

On 2026-08-21 at 14:23:20, Alexey Samsonov via GitGitGadget wrote:
> utime() function for setting access/modification time for files (and a
> corresponding <utime.h> header) have been officially removed from POSIX
> starting from POSIX.1-2024. While existing system library implementations
> still provide this function for compatibility reasons, its implementation
> may be removed in the future, or otherwise degrade over time. Some newer
> libc implementations (e.g. LLVM-libc, currently under development) don't
> provide utime() function at all.
> 
> This PR switches the git codebase to recommended alternative: utimensat()
> POSIX function (which supports nanosecond-level precision) from <fcntl.h>,
> and, as a possible fallback for older systems compatibility, utimes()
> function from <sys/stat.h>. It also provides the corresponding MinGW
> wrapper.

I seem to remember that we cannot use the *at functions because of
Windows and the fact that it doesn't offer the proper semantics.  I'm
curious as to how you did this, but I didn't read the series because of
the below.

> The alternative is to unconditionally use utimes() where possible, but given
> that utimensat is available in glibc starting from 2007, and on BSD systems
> since 2012 or so, it makes sense to use the newer variant by default.
> 
> No behavior changes is intended or expected (except for Git explicitly
> passing nanosecond-precision timestamps to kernel, where previously only
> second-level precision was used).
> 
> This change is generated by Gemini Flash from Antigravity, but all the code
> has been manually verified by me, and, where applicable, adjusted to match
> the existing behavior as closely as possible.

Unfortunately, I don't think that's allowed.  From SubmittingPatches[0]:

    The Developer's Certificate of Origin requires contributors to certify
    that they know the origin of their contributions to the project and
    that they have the right to submit it under the project's license.
    It's not yet clear that this can be legally satisfied when submitting
    significant amount of content that has been generated by AI tools.

I therefore haven't read this series to avoid being influenced by code
we're not allowed to include.

[0] https://git-scm.com/docs/SubmittingPatches#ai
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]