treewide: migrate from legacy utime.h to utimensat
Subsystems (2)
cover treewide: migrate from legacy utime.h to utimensat
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.
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.
Alexey Samsonov (3):
compat/posix: introduce utimensat(2) wrapper
treewide: use utimensat(2) instead of legacy utime(3p) compat/posix: drop legacy <utime.h> header and shims
Makefile | 6 +++++ builtin/pack-objects.c | 12 +++++---- commit-graph.c | 17 +++++-------- compat/mingw-posix.h | 4 +-- compat/mingw.c | 36 ++++++++++++++++++++------ compat/posix.h | 22 +++++++++++++++- compat/utimensat.c | 39 +++++++++++++++++++++++++++++ compat/vcbuild/include/sys/utime.h | 34 ------------------------- compat/vcbuild/include/utime.h | 1 - configure.ac | 6 +++++ contrib/buildsystems/CMakeLists.txt | 8 ++++-- copy.c | 10 +++++--- meson.build | 2 ++ object-file.c | 12 +++++---- odb/source-loose.c | 10 ++++---- odb/source-packed.c | 12 +++++---- rerere.c | 4 +-- t/helper/test-chmtime.c | 20 +++++++++------ t/t4051/includes.c | 1 - 19 files changed, 163 insertions(+), 93 deletions(-) create mode 100644 compat/utimensat.c delete mode 100644 compat/vcbuild/include/sys/utime.h delete mode 100644 compat/vcbuild/include/utime.h
base-commit: dea0ea3582e6980ddbc1173cc8e3e9f9db91cde0
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2209%2Fvonosmas%2Fdrop-utime-h-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2209/vonosmas/drop-utime-h-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2209
Signature · 1 line
gitgitgadget
PATCH 1/3 compat/posix: introduce utimensat(2) wrapper
From: Alexey Samsonov <[email protected]>
In POSIX.1-2008, utime(3p) was marked as obsolescent in favor of utimensat(2) and futimens(2). In the recent POSIX.1-2024 (Issue 8) specification, <utime.h> and utime(3p) were officially removed.
utimensat(2) operates on struct timespec rather than the second-only struct utimbuf, allowing sub-second timestamp updates while also providing support for UTIME_NOW and UTIME_OMIT flags to selectively update or preserve individual access and modification timestamps.
Introduce a compatibility layer for utimensat(2):
- Provide fallback definitions for AT_FDCWD, UTIME_NOW, and UTIME_OMIT in case the system headers lack them.
- Introduce ST_ATIME_NSEC(st) to complement ST_MTIME_NSEC(st) and ST_CTIME_NSEC(st).
- Implement git_utimensat() in compat/utimensat.c as a fallback using utimes(2) on platforms that define NO_UTIMENSAT.
- Implement mingw_utimensat() in compat/mingw.c converting struct timespec to Windows FILETIME with 100ns precision.
- Wire up NO_UTIMENSAT support in Makefile, meson.build, contrib/buildsystems/CMakeLists.txt, and configure.ac.
Subsequent commits will migrate callers across the codebase to utimensat(2) and drop the legacy <utime.h> header.
--- Makefile | 6 ++++ compat/mingw-posix.h | 2 ++ compat/mingw.c | 52 +++++++++++++++++++++++++---- compat/posix.h | 21 ++++++++++++ compat/utimensat.c | 39 ++++++++++++++++++++++ configure.ac | 6 ++++ contrib/buildsystems/CMakeLists.txt | 8 +++-- meson.build | 2 ++ 8 files changed, 127 insertions(+), 9 deletions(-) create mode 100644 compat/utimensat.c
Makefile +6 -0
@@ -70,6 +70,8 @@ include shared.mak # # Define NO_MKDTEMP if you don't have mkdtemp in the C library. # +# Define NO_UTIMENSAT if you don't have utimensat. +# # Define MKDIR_WO_TRAILING_SLASH if your mkdir() can't deal with trailing slash. # # Define NO_GECOS_IN_PWENT if you don't have pw_gecos in struct passwd
@@ -2049,6 +2051,10 @@ ifdef NO_WRITEV COMPAT_CFLAGS += -DNO_WRITEV COMPAT_OBJS += compat/writev.o endif +ifdef NO_UTIMENSAT + COMPAT_CFLAGS += -DNO_UTIMENSAT + COMPAT_OBJS += compat/utimensat.o +endif ifdef NO_FAST_WORKING_DIRECTORY BASIC_CFLAGS += -DNO_FAST_WORKING_DIRECTORY endif
compat/mingw-posix.h +2 -0
@@ -386,6 +386,8 @@ int mingw_fstat(int fd, struct stat *buf);int mingw_utime (const char *file_name,const struct utimbuf *times);#define utime mingw_utime +int mingw_utimensat (int fd,const char *path,const struct timespec times[2 ],int flag); +#define utimensat mingw_utimensatsize_t mingw_strftime (char *s,size_t max,const char *format,const struct tm *tm);#define strftime mingw_strftime
compat/mingw.c +45 -7
87 lines not on this page · raw message
compat/posix.h +21 -0
@@ -348,6 +348,24 @@ struct git_iovec {ssize_t git_writev (int fd,const struct iovec *iov,int iovcnt);#endif +#ifndef AT_FDCWD +#define AT_FDCWD (-100) +#endif +#ifndef UTIME_NOW +#define UTIME_NOW ((1L << 30) - 1L) +#endif +#ifndef UTIME_OMIT +#define UTIME_OMIT ((1L << 30) - 2L) +#endif + +#ifdef NO_UTIMENSAT +#ifdef utimensat +#undef utimensat +#endif +#define utimensat git_utimensat +int git_utimensat (int fd,const char *path,const struct timespec times[2 ],int flag); +#endif +#ifdef NO_SETENV #define setenv gitsetenvint gitsetenv (const char *,const char *,int );
@@ -502,13 +520,16 @@ int git_qsort_s(void *base, size_t nmemb, size_t size,#ifdef NO_NSEC #undef USE_NSEC +#define ST_ATIME_NSEC (st) 0#define ST_CTIME_NSEC (st) 0#define ST_MTIME_NSEC (st) 0#else #ifdef USE_ST_TIMESPEC +#define ST_ATIME_NSEC (st) ((unsigned int)((st).st_atimespec.tv_nsec))#define ST_CTIME_NSEC (st) ((unsigned int)((st).st_ctimespec.tv_nsec))#define ST_MTIME_NSEC (st) ((unsigned int)((st).st_mtimespec.tv_nsec))#else +#define ST_ATIME_NSEC (st) ((unsigned int)((st).st_atim.tv_nsec))#define ST_CTIME_NSEC (st) ((unsigned int)((st).st_ctim.tv_nsec))#define ST_MTIME_NSEC (st) ((unsigned int)((st).st_mtim.tv_nsec))#endif
compat/utimensat.c new file +39 -0
@@ -0,0 +1,39 @@ +#include "../git-compat-util.h" + +int git_utimensat (int fd,const char *path,const struct timespec times[2 ],int flag) +{ +struct timeval tv[2 ]; +struct timeval *tvp =NULL ; + +if (fd !=AT_FDCWD ) { + errno =ENOSYS ; +return -1 ; + } + +if (flag) { + errno =ENOSYS ; +return -1 ; + } + +if (times) { +for (int i =0 ; i <2 ; i++) { +if (times[i].tv_nsec ==UTIME_NOW ) { +struct timeval now; +gettimeofday (&now,NULL ); + tv[i] = now; + }else if (times[i].tv_nsec ==UTIME_OMIT ) { +struct stat st; +if (stat (path, &st) <0 ) +return -1 ; + tv[i].tv_sec = (i ==0 ) ? st.st_atime : st.st_mtime; + tv[i].tv_usec = (i ==0 ) ?ST_ATIME_NSEC (st) /1000 :ST_MTIME_NSEC (st) /1000 ; + }else { + tv[i].tv_sec = times[i].tv_sec; + tv[i].tv_usec = times[i].tv_nsec /1000 ; + } + } + tvp = tv; + } + +return utimes (path, tvp); +}
configure.ac +6 -0
@@ -1146,6 +1146,12 @@ GIT_CHECK_FUNC(mkdtemp, [NO_MKDTEMP=YesPlease]) GIT_CONF_SUBST([NO_MKDTEMP]) # +# Define NO_UTIMENSAT if you don't have utimensat in the C library. +GIT_CHECK_FUNC(utimensat, +[NO_UTIMENSAT=], +[NO_UTIMENSAT=YesPlease]) +GIT_CONF_SUBST([NO_UTIMENSAT]) +# # Define NO_INITGROUPS if you don't have initgroups in the C library. GIT_CHECK_FUNC(initgroups, [NO_INITGROUPS=],
contrib/buildsystems/CMakeLists.txt +6 -2
@@ -380,9 +380,9 @@ set(function_checks strcasestr memmem strlcpy strtoimax strtoumax strtoull setenv mkdtemp poll pread memmem writev) -#unsetenv,hstrerror are incompatible with windows build +#unsetenv,hstrerror,utimensat are incompatible with windows build (provided by compat/mingw.c) if(NOT WIN32) - list(APPEND function_checks unsetenv hstrerror) + list(APPEND function_checks unsetenv hstrerror utimensat) endif() foreach(f ${function_checks})
@@ -428,6 +428,10 @@ if(NOT HAVE_WRITEV) endif() if(NOT WIN32) + if(NOT HAVE_UTIMENSAT) + list(APPEND compat_SOURCES compat/utimensat.c) + endif() + if(NOT HAVE_UNSETENV) list(APPEND compat_SOURCES compat/unsetenv.c) endif()
meson.build +2 -0
@@ -1475,6 +1475,8 @@ else 'unsetenv' : ['unsetenv.c'], # provided by compat/mingw.c. 'getpagesize' : [], + # provided by compat/mingw.c. + 'utimensat' : ['utimensat.c'], } if get_option('b_sanitize').contains('address') or get_option('b_sanitize').contains('leak')
Signature · 1 line
gitgitgadget
PATCH 2/3 treewide: use utimensat(2) instead of legacy utime(3p)
In reply to Alexey Samsonov via GitGitGadgetFrom: Alexey Samsonov <[email protected]>
Now that a compatibility wrapper for utimensat(2) has been introduced, migrate all call sites across the codebase to use utimensat(2) instead of the legacy utime(3p) interface:
- In commit-graph.c, use utimensat(2) with UTIME_OMIT and the computed timestamp now to bump the commit-graph modification time consistently across all files without needing an extra stat(2) call to preserve atime.
- In copy.c, use utimensat(2) to copy full sub-second access and modification timestamps from the source file.
- In odb/source-packed.c, odb/source-loose.c, and object-file.c, use utimensat(2) with struct timespec to freshen file timestamps.
- In builtin/pack-objects.c, update the pack timestamp with utimensat(2).
- In rerere.c, touch the postimage file with utimensat(2) passing NULL to set both atime and mtime to current time.
- In t/helper/test-chmtime.c, update file modification times using utimensat(2).
--- builtin/pack-objects.c | 12 +++++++----- commit-graph.c | 17 ++++++----------- copy.c | 10 ++++++---- object-file.c | 12 +++++++----- odb/source-loose.c | 10 +++++----- odb/source-packed.c | 12 +++++++----- rerere.c | 4 ++-- t/helper/test-chmtime.c | 19 ++++++++++++------- 8 files changed, 52 insertions(+), 44 deletions(-)
builtin/pack-objects.c +7 -5
@@ -1438,11 +1438,13 @@ static void write_pack_file(void) }else if (!last_mtime) { last_mtime = st.st_mtime; }else { -struct utimbuf utb; - utb.actime = st.st_atime; - utb.modtime = --last_mtime; -if (utime (pack_tmp_name, &utb) <0 ) -warning_errno (_ ("failed utime() on %s" ), pack_tmp_name); +struct timespec times[2 ]; + times[0 ].tv_sec = st.st_atime; + times[0 ].tv_nsec =ST_ATIME_NSEC (st); + times[1 ].tv_sec = --last_mtime; + times[1 ].tv_nsec =0 ; +if (utimensat (AT_FDCWD , pack_tmp_name, times,0 ) <0 ) +warning_errno (_ ("failed utimensat() on %s" ), pack_tmp_name); } strbuf_addf(&tmpname, "%s-%s.", base_name,
commit-graph.c +6 -11
@@ -2484,18 +2484,13 @@ static void mark_commit_graphs(struct write_commit_graph_context *ctx) {uint32_t i;time_t now =time (NULL ); +struct timespec times[2 ] = { + { .tv_nsec =UTIME_OMIT }, + { .tv_sec = now, .tv_nsec =0 }, + }; -for (i = ctx->num_commit_graphs_after -1 ; i < ctx->num_commit_graphs_before; i++) { -struct stat st; -struct utimbuf updated_time; - -if (stat (ctx->commit_graph_filenames_before[i], &st) <0 ) -continue ; - - updated_time.actime = st.st_atime; - updated_time.modtime = now; -utime (ctx->commit_graph_filenames_before[i], &updated_time); - } +for (i = ctx->num_commit_graphs_after -1 ; i < ctx->num_commit_graphs_before; i++) +utimensat (AT_FDCWD , ctx->commit_graph_filenames_before[i], times,0 ); }static void expire_commit_graphs (struct write_commit_graph_context *ctx)
copy.c +6 -4
@@ -23,12 +23,14 @@ int copy_fd(int ifd, int ofd)static int copy_times (const char *dst,const char *src) {struct stat st; -struct utimbuf times; +struct timespec times[2 ];if (stat (src, &st) <0 )return -1 ; - times.actime = st.st_atime; - times.modtime = st.st_mtime; -if (utime (dst, ×) <0 ) + times[0 ].tv_sec = st.st_atime; + times[0 ].tv_nsec =ST_ATIME_NSEC (st); + times[1 ].tv_sec = st.st_mtime; + times[1 ].tv_nsec =ST_MTIME_NSEC (st); +if (utimensat (AT_FDCWD , dst, times,0 ) <0 )return -1 ;return 0 ; }
object-file.c +7 -5
@@ -69,15 +69,17 @@ const char *odb_loose_path(struct odb_source_loose *loose,/* Returns 1 if we have successfully freshened the file, 0 otherwise. */ static int freshen_file (const char *fn,const time_t *mtime) { -struct utimbuf times, *timesp =NULL ; +struct timespec times[2 ], *timesp =NULL ;if (mtime) { - times.actime = *mtime; - times.modtime = *mtime; - timesp = × + times[0 ].tv_sec = *mtime; + times[0 ].tv_nsec =0 ; + times[1 ].tv_sec = *mtime; + times[1 ].tv_nsec =0 ; + timesp = times; } -return !utime (fn, timesp); +return !utimensat (AT_FDCWD , fn, timesp,0 ); }/*
odb/source-loose.c +5 -5
@@ -807,14 +807,14 @@ static int write_loose_object(struct odb_source_loose *loose,close_loose_object (loose, fd, tmp_file.buf);if (mtime) { -struct utimbuf utb = { - .actime = *mtime, - .modtime = *mtime, +struct timespec times[2 ] = { + { .tv_sec = *mtime }, + { .tv_sec = *mtime }, }; -if (utime (tmp_file.buf, &utb) <0 && +if (utimensat (AT_FDCWD , tmp_file.buf, times,0 ) <0 && !(flags &ODB_WRITE_OBJECT_SILENT )) -warning_errno (_ ("failed utime() on %s" ), tmp_file.buf); +warning_errno (_ ("failed utimensat() on %s" ), tmp_file.buf); } return finalize_object_file_flags(loose->base.odb->repo, tmp_file.buf, filename.buf,
odb/source-packed.c +7 -5
@@ -574,13 +574,15 @@ static int odb_source_packed_freshen_object(struct odb_source *source, const time_t *mtime) {struct odb_source_packed *packed =odb_source_packed_downcast (source); -struct utimbuf times, *timesp =NULL ; +struct timespec times[2 ], *timesp =NULL ;struct pack_entry e;if (mtime) { - times.actime = *mtime; - times.modtime = *mtime; - timesp = × + times[0 ].tv_sec = *mtime; + times[0 ].tv_nsec =0 ; + times[1 ].tv_sec = *mtime; + times[1 ].tv_nsec =0 ; + timesp = times; }if (!find_pack_entry (packed, oid, &e))
@@ -589,7 +591,7 @@ static int odb_source_packed_freshen_object(struct odb_source *source,return 0 ;if (e.p->freshened)return 1 ; -if (utime (e.p->pack_name, timesp)) +if (utimensat (AT_FDCWD , e.p->pack_name, timesp,0 ))return 0 ; e.p->freshened =1 ;
rerere.c +2 -2
@@ -658,8 +658,8 @@ static int merge(struct index_state *istate, const struct rerere_id *id, const c* A successful replay of recorded resolution. * Mark that "postimage" was used to help gc. */ -if (utime (rerere_path (&buf, id,"postimage" ),NULL ) <0 ) -warning_errno (_ ("failed utime() on '%s'" ), +if (utimensat (AT_FDCWD ,rerere_path (&buf, id,"postimage" ),NULL ,0 ) <0 ) +warning_errno (_ ("failed utimensat() on '%s'" ),rerere_path (&buf, id,"postimage" ));/* Update "path" with the resolution */
t/helper/test-chmtime.c +12 -7
@@ -105,7 +105,8 @@ int cmd__chmtime(int argc, const char **argv)for (; i < argc; i++) {struct stat sb; -struct utimbuf utb; +struct timespec times[2 ]; +int64_t mtime_sec;uintmax_t mtime;if (stat (argv[i], &sb) <0 ) {
@@ -123,22 +124,26 @@ int cmd__chmtime(int argc, const char **argv) }#endif - utb.actime = sb.st_atime; - utb.modtime = set_eq ? set_time : sb.st_mtime + set_time; + mtime_sec = set_eq ? set_time : sb.st_mtime + set_time; - mtime = utb.modtime <0 ?0 : utb.modtime; + times[0 ].tv_sec = sb.st_atime; + times[0 ].tv_nsec =ST_ATIME_NSEC (sb); + times[1 ].tv_sec = mtime_sec; + times[1 ].tv_nsec =0 ; + + mtime = mtime_sec <0 ?0 : mtime_sec;if (get) {printf ("%" PRIuMAX"\n" , mtime); }else if (verbose) {printf ("%" PRIuMAX"\t%s\n" , mtime, argv[i]); } -if (utb.modtime != sb.st_mtime &&utime (argv[i], &utb) <0 ) { +if (mtime_sec != sb.st_mtime &&utimensat (AT_FDCWD , argv[i], times,0 ) <0 ) {#ifdef GIT_WINDOWS_NATIVE if (S_ISDIR (sb.st_mode)) {/* -* NEEDSWORK: The Windows version of `utime()` -* (aka `mingw_utime()`) does not correctly +* NEEDSWORK: The Windows version of `utimensat()` +* (aka `mingw_utimensat()`) does not correctly * handle directory arguments, since it uses * `_wopen()`. Ignore it for now since this * is just a test.
Signature · 1 line
gitgitgadget
PATCH 3/3 compat/posix: drop legacy <utime.h> header and shims
In reply to Alexey Samsonov via GitGitGadgetFrom: Alexey Samsonov <[email protected]>
With all callers across the codebase now converted to utimensat(2), we no longer need to include the legacy <utime.h> header in compat/posix.h.
Remove #include <utime.h> from compat/posix.h and test fixtures, remove mingw_utime() from compat/mingw.c, and delete the legacy header shims in compat/vcbuild/include/.
--- compat/mingw-posix.h | 2 -- compat/mingw.c | 16 -------------- compat/posix.h | 1 - compat/vcbuild/include/sys/utime.h | 34 ------------------------------ compat/vcbuild/include/utime.h | 1 - t/helper/test-chmtime.c | 1 - t/t4051/includes.c | 1 - 7 files changed, 56 deletions(-) delete mode 100644 compat/vcbuild/include/sys/utime.h delete mode 100644 compat/vcbuild/include/utime.h
compat/mingw-posix.h +0 -2
@@ -384,8 +384,6 @@ int mingw_fstat(int fd, struct stat *buf);#define lstat mingw_lstat -int mingw_utime (const char *file_name,const struct utimbuf *times); -#define utime mingw_utimeint mingw_utimensat (int fd,const char *path,const struct timespec times[2 ],int flag);#define utimensat mingw_utimensat size_t mingw_strftime(char *s, size_t max,
compat/mingw.c +0 -16
@@ -1480,22 +1480,6 @@ revert_attrs:return rc; } -int mingw_utime (const char *file_name,const struct utimbuf *times) -{ -struct timespec ts[2 ]; -struct timespec *tsp =NULL ; - -if (times) { - ts[0 ].tv_sec = times->actime; - ts[0 ].tv_nsec =0 ; - ts[1 ].tv_sec = times->modtime; - ts[1 ].tv_nsec =0 ; - tsp = ts; - } - -return mingw_utimensat (AT_FDCWD , file_name, tsp,0 ); -} -#undef strftimesize_t mingw_strftime (char *s,size_t max,const char *format,const struct tm *tm)
compat/posix.h +0 -1
@@ -123,7 +123,6 @@#include <signal.h> #include <assert.h> #include <regex.h> -#include <utime.h> #include <syslog.h> #if !defined(NO_POLL_H )#include <poll.h>
compat/vcbuild/include/sys/utime.h deleted +0 -34
@@ -1,34 +0,0 @@ -#ifndef _UTIME_H_ -#define _UTIME_H_ -/* -* UTIME.H -* This file has no copyright assigned and is placed in the Public Domain. -* This file is a part of the mingw-runtime package. -* -* The mingw-runtime package and its code is distributed in the hope that it -* will be useful but WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESSED OR -* IMPLIED ARE HEREBY DISCLAIMED. This includes but is not limited to -* warranties of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -* -* You are free to use this package and its code without limitation. -*/ - -/* -* Structure used by _utime function. -*/ -struct _utimbuf -{ -time_t actime;/* Access time */ -time_t modtime;/* Modification time */ -}; - -#ifndef _NO_OLDNAMES -/* NOTE: Must be the same as _utimbuf above. */ -struct utimbuf -{ -time_t actime; -time_t modtime; -}; -#endif /* Not _NO_OLDNAMES */ - -#endif
compat/vcbuild/include/utime.h deleted +0 -1
@@ -1 +0,0 @@ -#include <sys/utime.h>
t/helper/test-chmtime.c +0 -1
@@ -38,7 +38,6 @@*/ #include "test-tool.h" #include "git-compat-util.h" -#include <utime.h> static const char usage_str[] ="(-v|--verbose|-g|--get) (+|=|=+|=-|-)<seconds> <file>..." ;
t/t4051/includes.c +0 -1
@@ -15,6 +15,5 @@#include <signal.h> #include <assert.h> #include <regex.h> -#include <utime.h> #include <syslog.h> #include <End.h>
Signature · 1 line
gitgitgadget
Quoted 14 lines · Alexey Samsonov via GitGitGadget
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 provideutime()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.
Quoted 3 lines
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.
I hear that Apple has supported it since macOS 10.13 High Sierra, which came out in 2017 and reached EOL in 2020, so we should be safe there as well.
Quoted 8 lines · Alexey Samsonov via GitGitGadget
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 provideutime()function at all.
Quoted 5 lines
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.
Quoted 11 lines
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
Signature · 2 lines
brian m. carlson (they/them) Toronto, Ontario, CA
Quoted 13 lines · brian m. carlson
Quoted 3 lines · Alexey Samsonov via GitGitGadget
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.
Quoted 4 lines
I therefore haven't read this series to avoid being influenced by code we're not allowed to include.
Your stance, as I understand it, is that Alexey's DCO is not valid because, acting as a copy editor of Antigravity/Gemini's work, Alexey cannot possibly know where the code was copied from. And we cannot accept work that is not covered by a valid DCO.
I think that is a much more prudent attitude than being cavalier about legal issues. I used to think, "Hey, the person claims in the DCO that the code is appropriately licensed, so if it turns out to be a false claim later, that is his or her problem, not ours."
But that is not how things work.
If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.
Stepping back a bit, though, is the situation really all that different between a relatively new author who discloses their use of AI and another author similarly unknown to us who claims it is all their own work? Either way, if the code turns out to be unusable, we would still be on the hook for participating in the infringement and would bear the cost of ripping it out.
What worries me a bit is that there may not be much difference between "you said that you relayed AI output, so we won't talk to you" and "we do not know you well enough to trust you, so we won't talk to you".
Quoted 18 lines · Junio C Hamano
Quoted 16 lines · brian m. carlson
Quoted 3 lines · Alexey Samsonov via GitGitGadget
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.
Quoted 6 lines
Quoted 1 line
Your stance, as I understand it, is that Alexey's DCO is not valid because, acting as a copy editor of Antigravity/Gemini's work, Alexey cannot possibly know where the code was copied from. And we cannot accept work that is not covered by a valid DCO.
Yes. We know that in some cases LLMs regurgitate code that is substantially similar to training inputs and we don't know what the legal status of the output of an LLM is, especially since there is active litigation around the world.
The DCO was invented to provide a legal assertion by an author that they are only submitting code they legally have the right to submit and I don't think there's enough legal clarity for us to know that with an LLM.
Quoted 6 lines
I think that is a much more prudent attitude than being cavalier about legal issues. I used to think, "Hey, the person claims in the DCO that the code is appropriately licensed, so if it turns out to be a false claim later, that is his or her problem, not ours."
But that is not how things work.
It's my understanding that in many places there's a difference between knowingly doing something and doing something without knowledge. For example, Canada's Copyright Act uses the text, "that the person knows or should have known infringes copyright".
So we do have more of a legal problem if we knowingly distribute code that infringes copyright or which we suspect may do so.
Quoted 5 lines
If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.
Yes, that's true. We still have the fallout and issues in terms of project management to deal with, but fewer legal problems.
Quoted 11 lines
Stepping back a bit, though, is the situation really all that different between a relatively new author who discloses their use of AI and another author similarly unknown to us who claims it is all their own work? Either way, if the code turns out to be unusable, we would still be on the hook for participating in the infringement and would bear the cost of ripping it out.
What worries me a bit is that there may not be much difference between "you said that you relayed AI output, so we won't talk to you" and "we do not know you well enough to trust you, so we won't talk to you".
If somebody comes to our project and lies to us about the provenance of their work, that's very serious. Saying, "I wrote this with AI," when we don't allow AI is being honest and ethical and disclosing relevant details to the project. It may be that we can't accept their code for that reason, but they have participated in the project in good faith. We could certainly accept other patches from such a person written without AI.
But if a contributor misleads us about the origin of their code, whether it came from AI or was taken without credit from another project, then they're not at all acting in good faith and we will likely not allow them to continue to contribute to the project. Moreover, they will also be unwelcome in most other projects as well because they'll be viewed as dishonest.
That doesn't affect whether we end up having negative consequences from distributing that code, true. But at some point, we have to trust that most people are honest or our community and society break down.
Signature · 2 lines
brian m. carlson (they/them) Toronto, Ontario, CA
[+cc Johannes Schindelin]
Quoted 30 lines · Junio C Hamano
Quoted 13 lines · brian m. carlson
Quoted 3 lines · Alexey Samsonov via GitGitGadget
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.
Quoted 4 lines
I therefore haven't read this series to avoid being influenced by code we're not allowed to include.
Your stance, as I understand it, is that Alexey's DCO is not valid because, acting as a copy editor of Antigravity/Gemini's work, Alexey cannot possibly know where the code was copied from. And we cannot accept work that is not covered by a valid DCO.
I think that is a much more prudent attitude than being cavalier about legal issues. I used to think, "Hey, the person claims in the DCO that the code is appropriately licensed, so if it turns out to be a false claim later, that is his or her problem, not ours."
Quoted 7 lines
But that is not how things work.
If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.
Sorry to interject here, but I seem to remember that dscho already has a few commits with an Assisted-by trailer that have made it into master. I´m not entirely sure what kind of assistance he received either, but as you suggest, it seems better to mention this here sooner rather than later.
(I also mentioned this part here [1], with full respect to Johannes)
Quoted 11 lines
Stepping back a bit, though, is the situation really all that different between a relatively new author who discloses their use of AI and another author similarly unknown to us who claims it is all their own work? Either way, if the code turns out to be unusable, we would still be on the hook for participating in the infringement and would bear the cost of ripping it out.
What worries me a bit is that there may not be much difference between "you said that you relayed AI output, so we won't talk to you" and "we do not know you well enough to trust you, so we won't talk to you".
But I think that, from Linus's point of view, the chain of trust matters more than whether AI was used in the first place:
| So AI giveth, and AI taketh away. But the basic issue shouldn't be AI | per se, it should be that notion of "trust". [2]
Of course, I also understand that the Git community doesn't need to completely follow the rules from kernel community.
Thanks.
[1] https://lore.kernel.org/git/[email protected]/
[2] https://lore.kernel.org/all/CAHk-=wgbGarE7Ozw4VG6oUKDj9pk-8DRoDiX00bo1MwEMm9UWQ@mail.gmail.com/
Quoted 5 lines · brian m. carlson
Quoted 4 lines · Junio C Hamano
Quoted 2 lines · brian m. carlson
I therefore haven't read this series to avoid being influenced by code we're not allowed to include.
More on this a bit later...
Quoted 2 lines
So we do have more of a legal problem if we knowingly distribute code that infringes copyright or which we suspect may do so.
Projects like the Linux kernel ask you to disclose your use of AI (and have other requirements on your use), but I haven't read exactly why they want it. I wish they instead said, "We do not want to be blamed for knowingly infringing. While we do not particularly encourage you to use AI, if you use one, do not tell us" ;-).
Quoted 7 lines
If somebody comes to our project and lies to us about the provenance of their work, that's very serious. Saying, "I wrote this with AI," when we don't allow AI is being honest and ethical and disclosing relevant details to the project. It may be that we can't accept their code for that reason, but they have participated in the project in good faith. We could certainly accept other patches from such a person written without AI.
But that contradicts what you yourself did, doesn't it? An honest developer who discloses their use of AI admits that their eyes are already contaminated by AI output, because they did not avoid being influenced as you did. So are they unwelcome now?
Stepping back a bit, even before the AI era, a human developer may have seen code elsewhere that they are not allowed to include in a particular project. Learning from what others did is the nature of our work, and it is inevitable. Is it reasonable for BSD-only projects to declare that those who are familiar with constructs that appear in Git code after working on it are unwelcome, because their contributions may be contaminated by what they have seen in a GPLed project?
I very much appreciate that you are treading very cautiously on the safer side, but I hope that the actual balance lies on a somewhat more practical side that trusts humans.
Quoted 3 lines
That doesn't affect whether we end up having negative consequences from distributing that code, true. But at some point, we have to trust that most people are honest or our community and society break down.
True. True.
Thanks.
Quoted 5 lines · Weijie Yuan
Sorry to interject here, but I seem to remember that dscho already has a few commits with an Assisted-by trailer that have made it into master. I´m not entirely sure what kind of assistance he received either, but as you suggest, it seems better to mention this here sooner rather than later.
We know Johannes well enough to trust that his patches were sent with sufficient due diligence. So...?
Quoted 10 lines · Junio C Hamano
Quoted 5 lines · Weijie Yuan
Sorry to interject here, but I seem to remember that dscho already has a few commits with an Assisted-by trailer that have made it into master. I´m not entirely sure what kind of assistance he received either, but as you suggest, it seems better to mention this here sooner rather than later.
We know Johannes well enough to trust that his patches were sent with sufficient due diligence. So...?
Quoted 5 lines
If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.
What I meant is that you said we should be wary of content that might carry legal risks, if I understand correctly. And as far as I remember, Johannes is the only person recently who has proactively disclosed that his patches were AI-assisted. I appreciate that disclosure, so I was simply pointing it out. Of course, I have no doubt about the quality of his patches.
So what I mean is that we have already had cases where people voluntarily disclosed their use of AI, but there did not seem to be much discussion about it at the time. This time, Brian brought the issue up for discussion, and I really appreciate both of you doing so.
Thanks.
Quoted 4 lines · Weijie Yuan
Quoted 2 lines
We know Johannes well enough to trust that his patches were sent with sufficient due diligence. So...?
Quoted 8 lines
Quoted 5 lines
If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.
What I meant is that you said we should be wary of content that might carry legal risks,...
I am not sure what your point is. Is there any part in "we trust Dscho well enough to trust that he sent them with sufficient due diligence" that was hard for you to understand?
Quoted 12 lines · Junio C Hamano
Quoted 10 lines · Weijie Yuan
Quoted 2 lines
We know Johannes well enough to trust that his patches were sent with sufficient due diligence. So...?
Quoted 5 lines
If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.
Quoted 6 lines
Quoted 2 lines
What I meant is that you said we should be wary of content that might carry legal risks,...
I am not sure what your point is. Is there any part in "we trust Dscho well enough to trust that he sent them with sufficient due diligence" that was hard for you to understand?
Apologies, and please forget it. I must be feeling dizzy.
Thanks.
Quoted 12 lines · Junio C Hamano
Quoted 10 lines · Weijie Yuan
Quoted 2 lines
We know Johannes well enough to trust that his patches were sent with sufficient due diligence. So...?
Quoted 5 lines
If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.
Quoted 6 lines
Quoted 2 lines
What I meant is that you said we should be wary of content that might carry legal risks,...
I am not sure what your point is. Is there any part in "we trust Dscho well enough to trust that he sent them with sufficient due diligence" that was hard for you to understand?
Sorry, I think I failed to make my actual question clear in my previous replies.
I do understand, and agree with, your point that you trust Johannes to have submitted his patches with sufficient due diligence. I was not trying to question Johannes or your trust in him.
What I was trying to understand is how that fits with the particular DCO concern being discussed here.
You pointed out that if something submitted under the DCO later turns out to be based on material we cannot legally use, the project also bears the cost of removing it, and that the fallout becomes worse the later such a problem is discovered.
As I understand brian's concern, if a significant amount of a contribution is generated by an AI tool, there may be uncertainty over whether the submitter can make the DCO certification with sufficient confidence.
That is why Johannes's existing commits with an Assisted-by trailer came to mind. I am not claiming that those commits necessarily contain AI-generated content of the kind brian is concerned about; I do not know what the assistance actually consisted of.
But if the disclosed assistance did involve generated content of that kind, wouldn't the same DCO question arise? And if we do not know whether it did, isn't that the sort of question that, following your point above, would be better clarified sooner rather than later?
At the same time, I can also see the point behind your:
"if you use one, do not tell us" ;-)
Thinking about it from that angle also makes me wonder about Assisted-by trailers themselves. If I understand the point behind "if you use one, do not tell us" correctly, then perhaps we should simply not encourage Assisted-by: LLM trailers, since such a trailer explicitly records the very fact that we might prefer the project not to be told about.
Of course, I am simply worried that an Assisted-by trailer might create some legal risk. I am not a lawyer, though, so I do not know whether that concern is actually well-founded.
On the other hand, I can also understand why the kernel community made a different trade-off and prefers disclosure. Knowing that a tool was involved gives the maintainer additional information, and the maintainer can then decide according to their own judgment whether that information should affect how the patch is handled. (possibly there are other reasons)
That was what I was trying, rather unsuccessfully, to get at before. I am sorry that my earlier replies made it sound as though I was singling out Johannes as a problematic case.
Sorry again for the confusion and the noise.
Thanks,
Weijie
Quoted 2 lines · Weijie Yuan
What I was trying to understand is how that fits with the particular DCO concern being discussed here.
You may never be able to tell where the AI output came from, but you can see if the updated code has resemblance to fixes we applied in the past to correct similar problems, for example. After all, you yourself without help by AI can copy our code to your patch to enhance our code, and that is perfectly legit.
Take for example 5fe676f448 (t1300: remove global config settings injected by test-lib.sh, 2026-04-26) that added
test_might_fail git config --global --unset-all safe.bareRepository
that clearly mimicked the tests that prepared the stage by clearing a relevant configuration variable done in an earier 313eec177a (safe.directory: allow "lead/ing/path/*" match, 2024-05-29).
By "sufficient due diligence", what I meant was that I trust Dscho well enough that he's done a similar analysis to make sure that he is copying from ourselves.
Quoted 3 lines · Junio C Hamano
By "sufficient due diligence", what I meant was that I trust Dscho well enough that he's done a similar analysis to make sure that he is copying from ourselves.
... or wrote things using what he learned from other places that are OK to copy from (like code of BSD licensed projects).
Quoted 20 lines
Quoted 2 lines · Weijie Yuan
What I was trying to understand is how that fits with the particular DCO concern being discussed here.
You may never be able to tell where the AI output came from, but you can see if the updated code has resemblance to fixes we applied in the past to correct similar problems, for example. After all, you yourself without help by AI can copy our code to your patch to enhance our code, and that is perfectly legit.
Take for example
5fe676f448(t1300: remove global config settings injected bytest-lib.sh, 2026-04-26) that addedtest_might_fail git config --global --unset-all safe.bareRepositorythat clearly mimicked the tests that prepared the stage by clearing a relevant configuration variable done in an earier
313eec177a(safe.directory: allow "lead/ing/path/*" match, 2024-05-29).
Quoted 6 lines
By "sufficient due diligence", what I meant was that I trust Dscho well enough that he's done a similar analysis to make sure that he is copying from ourselves.
... or wrote things using what he learned from other places that are OK to copy from (like code of BSD licensed projects).
Ah, I see it clearly now. This could make us able to keep the provenance of the patch under control.
Thanks so much for taking the time to give me this example and explanation. And very sorry for bringing Dscho into the discussion, sorry.
Apologize for my recklessness. Thank you very much.
Quoted 4 lines · Junio C Hamano
By "sufficient due diligence", what I meant was that I trust Dscho well enough that he's done a similar analysis to make sure that he is copying from ourselves.
i think the salient point is that it is never reasonable to make that assumption when an AI tool is used. some of the tools now reportedly detect themselves when they are outright plagiarizing (and identifying the tool in a trailer would actually give some assurance in that regard), but if the tool fails or doesn't have the feature in the first place, then all bets are off. Literally No-one (TM) will use multiple code search engines to check whether the generated code doesn't contain sufficiently large fragments that are (near-)verbatim copies from incompatibly licensed code bases.