* [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
@ 2026-08-21 14:23 Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 1/3] compat/posix: introduce utimensat(2) wrapper Alexey Samsonov via GitGitGadget
` (4 more replies)
0 siblings, 5 replies; 19+ messages in thread
From: Alexey Samsonov via GitGitGadget @ 2026-08-21 14:23 UTC (permalink / raw)
To: git; +Cc: Alexey Samsonov
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.
Signed-off-by: Alexey Samsonov vonosmas@gmail.com
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
--
gitgitgadget
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 1/3] compat/posix: introduce utimensat(2) wrapper
2026-08-21 14:23 [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat Alexey Samsonov via GitGitGadget
@ 2026-08-21 14:23 ` Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 2/3] treewide: use utimensat(2) instead of legacy utime(3p) Alexey Samsonov via GitGitGadget
` (3 subsequent siblings)
4 siblings, 0 replies; 19+ messages in thread
From: Alexey Samsonov via GitGitGadget @ 2026-08-21 14:23 UTC (permalink / raw)
To: git; +Cc: Alexey Samsonov, Alexey Samsonov
From: Alexey Samsonov <vonosmas@gmail.com>
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.
Signed-off-by: Alexey Samsonov <vonosmas@gmail.com>
---
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
diff --git a/Makefile b/Makefile
index d4b775953d..64909d48b2 100644
--- a/Makefile
+++ b/Makefile
@@ -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
diff --git a/compat/mingw-posix.h b/compat/mingw-posix.h
index 2d989fd762..aab91d76db 100644
--- a/compat/mingw-posix.h
+++ b/compat/mingw-posix.h
@@ -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_utimensat
size_t mingw_strftime(char *s, size_t max,
const char *format, const struct tm *tm);
#define strftime mingw_strftime
diff --git a/compat/mingw.c b/compat/mingw.c
index 4c2f26d454..d09a976191 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1391,22 +1391,33 @@ int mingw_fstat(int fd, struct stat *buf)
}
}
-static inline void time_t_to_filetime(time_t t, FILETIME *ft)
+static inline void timespec_to_filetime(const struct timespec *ts, FILETIME *ft)
{
- long long winTime = t * 10000000LL + 116444736000000000LL;
+ long long winTime = (long long)ts->tv_sec * 10000000LL + (ts->tv_nsec / 100) + 116444736000000000LL;
ft->dwLowDateTime = winTime;
ft->dwHighDateTime = winTime >> 32;
}
-int mingw_utime (const char *file_name, const struct utimbuf *times)
+int mingw_utimensat(int fd, const char *path, const struct timespec times[2], int flag)
{
FILETIME mft, aft;
+ FILETIME *paft = &aft, *pmft = &mft;
int rc;
DWORD attrs;
wchar_t wfilename[MAX_PATH];
HANDLE osfilehandle;
- if (xutftowcs_path(wfilename, file_name) < 0)
+ if (fd != AT_FDCWD) {
+ errno = ENOSYS;
+ return -1;
+ }
+
+ if (flag) {
+ errno = ENOSYS;
+ return -1;
+ }
+
+ if (xutftowcs_path(wfilename, path) < 0)
return -1;
/* must have write permission */
@@ -1433,14 +1444,25 @@ int mingw_utime (const char *file_name, const struct utimbuf *times)
}
if (times) {
- time_t_to_filetime(times->modtime, &mft);
- time_t_to_filetime(times->actime, &aft);
+ if (times[0].tv_nsec == UTIME_NOW)
+ GetSystemTimeAsFileTime(&aft);
+ else if (times[0].tv_nsec == UTIME_OMIT)
+ paft = NULL;
+ else
+ timespec_to_filetime(×[0], &aft);
+
+ if (times[1].tv_nsec == UTIME_NOW)
+ GetSystemTimeAsFileTime(&mft);
+ else if (times[1].tv_nsec == UTIME_OMIT)
+ pmft = NULL;
+ else
+ timespec_to_filetime(×[1], &mft);
} else {
GetSystemTimeAsFileTime(&mft);
aft = mft;
}
- if (!SetFileTime(osfilehandle, NULL, &aft, &mft)) {
+ if (!SetFileTime(osfilehandle, NULL, paft, pmft)) {
errno = EINVAL;
rc = -1;
} else
@@ -1458,6 +1480,22 @@ 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 strftime
size_t mingw_strftime(char *s, size_t max,
const char *format, const struct tm *tm)
diff --git a/compat/posix.h b/compat/posix.h
index 71cc731620..3cac1751aa 100644
--- a/compat/posix.h
+++ b/compat/posix.h
@@ -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 gitsetenv
int 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
diff --git a/compat/utimensat.c b/compat/utimensat.c
new file mode 100644
index 0000000000..e4c8e8d0b6
--- /dev/null
+++ b/compat/utimensat.c
@@ -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);
+}
diff --git a/configure.ac b/configure.ac
index cfb50112bf..a37a53f5b5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -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=],
diff --git a/contrib/buildsystems/CMakeLists.txt b/contrib/buildsystems/CMakeLists.txt
index 8f56203f34..bb1d96802d 100644
--- a/contrib/buildsystems/CMakeLists.txt
+++ b/contrib/buildsystems/CMakeLists.txt
@@ -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()
diff --git a/meson.build b/meson.build
index d86f2acd2b..a98f63a46c 100644
--- a/meson.build
+++ b/meson.build
@@ -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')
--
gitgitgadget
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 2/3] treewide: use utimensat(2) instead of legacy utime(3p)
2026-08-21 14:23 [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 1/3] compat/posix: introduce utimensat(2) wrapper Alexey Samsonov via GitGitGadget
@ 2026-08-21 14:23 ` Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 3/3] compat/posix: drop legacy <utime.h> header and shims Alexey Samsonov via GitGitGadget
` (2 subsequent siblings)
4 siblings, 0 replies; 19+ messages in thread
From: Alexey Samsonov via GitGitGadget @ 2026-08-21 14:23 UTC (permalink / raw)
To: git; +Cc: Alexey Samsonov, Alexey Samsonov
From: Alexey Samsonov <vonosmas@gmail.com>
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).
Signed-off-by: Alexey Samsonov <vonosmas@gmail.com>
---
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(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 1ec5b6f206..35bdbc2b6a 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -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,
diff --git a/commit-graph.c b/commit-graph.c
index 49e8f63930..08bbba3d98 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -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)
diff --git a/copy.c b/copy.c
index 6074132050..39673f7829 100644
--- a/copy.c
+++ b/copy.c
@@ -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;
}
diff --git a/object-file.c b/object-file.c
index ec35c318bc..5e4ccb36d5 100644
--- a/object-file.c
+++ b/object-file.c
@@ -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);
}
/*
diff --git a/odb/source-loose.c b/odb/source-loose.c
index ef0e919277..1fdaa9f88f 100644
--- a/odb/source-loose.c
+++ b/odb/source-loose.c
@@ -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,
diff --git a/odb/source-packed.c b/odb/source-packed.c
index 0890704e76..64871ff8da 100644
--- a/odb/source-packed.c
+++ b/odb/source-packed.c
@@ -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;
diff --git a/rerere.c b/rerere.c
index 3d3bd0db16..b64771f57f 100644
--- a/rerere.c
+++ b/rerere.c
@@ -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 */
diff --git a/t/helper/test-chmtime.c b/t/helper/test-chmtime.c
index 0e5538833a..a9e6eb78b8 100644
--- a/t/helper/test-chmtime.c
+++ b/t/helper/test-chmtime.c
@@ -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.
--
gitgitgadget
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 3/3] compat/posix: drop legacy <utime.h> header and shims
2026-08-21 14:23 [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 1/3] compat/posix: introduce utimensat(2) wrapper Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 2/3] treewide: use utimensat(2) instead of legacy utime(3p) Alexey Samsonov via GitGitGadget
@ 2026-08-21 14:23 ` Alexey Samsonov via GitGitGadget
2026-08-21 17:33 ` [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat Junio C Hamano
2026-08-22 16:03 ` brian m. carlson
4 siblings, 0 replies; 19+ messages in thread
From: Alexey Samsonov via GitGitGadget @ 2026-08-21 14:23 UTC (permalink / raw)
To: git; +Cc: Alexey Samsonov, Alexey Samsonov
From: Alexey Samsonov <vonosmas@gmail.com>
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/`.
Signed-off-by: Alexey Samsonov <vonosmas@gmail.com>
---
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
diff --git a/compat/mingw-posix.h b/compat/mingw-posix.h
index aab91d76db..286ca24002 100644
--- a/compat/mingw-posix.h
+++ b/compat/mingw-posix.h
@@ -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_utime
int 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,
diff --git a/compat/mingw.c b/compat/mingw.c
index d09a976191..e2ec44fdd2 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -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 strftime
size_t mingw_strftime(char *s, size_t max,
const char *format, const struct tm *tm)
diff --git a/compat/posix.h b/compat/posix.h
index 3cac1751aa..435ed90f56 100644
--- a/compat/posix.h
+++ b/compat/posix.h
@@ -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>
diff --git a/compat/vcbuild/include/sys/utime.h b/compat/vcbuild/include/sys/utime.h
deleted file mode 100644
index 582589c70a..0000000000
--- a/compat/vcbuild/include/sys/utime.h
+++ /dev/null
@@ -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
diff --git a/compat/vcbuild/include/utime.h b/compat/vcbuild/include/utime.h
deleted file mode 100644
index 8285f38fde..0000000000
--- a/compat/vcbuild/include/utime.h
+++ /dev/null
@@ -1 +0,0 @@
-#include <sys/utime.h>
diff --git a/t/helper/test-chmtime.c b/t/helper/test-chmtime.c
index a9e6eb78b8..295f55cf47 100644
--- a/t/helper/test-chmtime.c
+++ b/t/helper/test-chmtime.c
@@ -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>...";
diff --git a/t/t4051/includes.c b/t/t4051/includes.c
index efc68f8bf6..4861f6657b 100644
--- a/t/t4051/includes.c
+++ b/t/t4051/includes.c
@@ -15,6 +15,5 @@
#include <signal.h>
#include <assert.h>
#include <regex.h>
-#include <utime.h>
#include <syslog.h>
#include <End.h>
--
gitgitgadget
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-21 14:23 [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat Alexey Samsonov via GitGitGadget
` (2 preceding siblings ...)
2026-08-21 14:23 ` [PATCH 3/3] compat/posix: drop legacy <utime.h> header and shims Alexey Samsonov via GitGitGadget
@ 2026-08-21 17:33 ` Junio C Hamano
2026-08-22 16:03 ` brian m. carlson
4 siblings, 0 replies; 19+ messages in thread
From: Junio C Hamano @ 2026-08-21 17:33 UTC (permalink / raw)
To: Alexey Samsonov via GitGitGadget; +Cc: git, Alexey Samsonov
"Alexey Samsonov via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 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.
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-21 14:23 [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat Alexey Samsonov via GitGitGadget
` (3 preceding siblings ...)
2026-08-21 17:33 ` [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat Junio C Hamano
@ 2026-08-22 16:03 ` brian m. carlson
2026-08-22 17:59 ` Junio C Hamano
4 siblings, 1 reply; 19+ messages in thread
From: brian m. carlson @ 2026-08-22 16:03 UTC (permalink / raw)
To: Alexey Samsonov via GitGitGadget; +Cc: git, Alexey Samsonov
[-- 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 --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-22 16:03 ` brian m. carlson
@ 2026-08-22 17:59 ` Junio C Hamano
2026-08-22 21:15 ` brian m. carlson
2026-08-23 13:26 ` Weijie Yuan
0 siblings, 2 replies; 19+ messages in thread
From: Junio C Hamano @ 2026-08-22 17:59 UTC (permalink / raw)
To: brian m. carlson; +Cc: Alexey Samsonov via GitGitGadget, git, Alexey Samsonov
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2026-08-21 at 14:23:20, Alexey Samsonov via GitGitGadget wrote:
>> 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
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".
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-22 17:59 ` Junio C Hamano
@ 2026-08-22 21:15 ` brian m. carlson
2026-08-23 15:23 ` Junio C Hamano
2026-08-23 13:26 ` Weijie Yuan
1 sibling, 1 reply; 19+ messages in thread
From: brian m. carlson @ 2026-08-22 21:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexey Samsonov via GitGitGadget, git, Alexey Samsonov
[-- Attachment #1: Type: text/plain, Size: 4660 bytes --]
On 2026-08-22 at 17:59:09, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > On 2026-08-21 at 14:23:20, Alexey Samsonov via GitGitGadget wrote:
> >> 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
>
> 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.
> 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.
> 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.
> 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.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-22 17:59 ` Junio C Hamano
2026-08-22 21:15 ` brian m. carlson
@ 2026-08-23 13:26 ` Weijie Yuan
2026-08-23 15:26 ` Junio C Hamano
1 sibling, 1 reply; 19+ messages in thread
From: Weijie Yuan @ 2026-08-23 13:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: brian m. carlson, Alexey Samsonov via GitGitGadget, git,
Alexey Samsonov, Johannes Schindelin
[+cc Johannes Schindelin]
On Sat, Aug 22, 2026 at 10:59:09AM -0700, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > On 2026-08-21 at 14:23:20, Alexey Samsonov via GitGitGadget wrote:
> >> 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
>
> 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.
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)
> 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/aorxVo_6_U1ceaKm@wyuan.org/
[2] https://lore.kernel.org/all/CAHk-=wgbGarE7Ozw4VG6oUKDj9pk-8DRoDiX00bo1MwEMm9UWQ@mail.gmail.com/
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-22 21:15 ` brian m. carlson
@ 2026-08-23 15:23 ` Junio C Hamano
0 siblings, 0 replies; 19+ messages in thread
From: Junio C Hamano @ 2026-08-23 15:23 UTC (permalink / raw)
To: brian m. carlson; +Cc: Alexey Samsonov via GitGitGadget, git, Alexey Samsonov
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2026-08-22 at 17:59:09, Junio C Hamano wrote:
>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>>
>> > 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...
> 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" ;-).
> 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.
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-23 13:26 ` Weijie Yuan
@ 2026-08-23 15:26 ` Junio C Hamano
2026-08-23 15:45 ` Weijie Yuan
0 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2026-08-23 15:26 UTC (permalink / raw)
To: Weijie Yuan
Cc: brian m. carlson, Alexey Samsonov via GitGitGadget, git,
Alexey Samsonov, Johannes Schindelin
Weijie Yuan <wy@wyuan.org> writes:
> 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...?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-23 15:26 ` Junio C Hamano
@ 2026-08-23 15:45 ` Weijie Yuan
2026-08-24 1:49 ` Junio C Hamano
0 siblings, 1 reply; 19+ messages in thread
From: Weijie Yuan @ 2026-08-23 15:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: brian m. carlson, Alexey Samsonov via GitGitGadget, git,
Alexey Samsonov, Johannes Schindelin
On Sun, Aug 23, 2026 at 08:26:40AM -0700, Junio C Hamano wrote:
> Weijie Yuan <wy@wyuan.org> writes:
>
> > 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...?
<xmqqzeyeujde.fsf@gitster.g>:
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-23 15:45 ` Weijie Yuan
@ 2026-08-24 1:49 ` Junio C Hamano
2026-08-24 12:19 ` Weijie Yuan
2026-08-24 15:33 ` Weijie Yuan
0 siblings, 2 replies; 19+ messages in thread
From: Junio C Hamano @ 2026-08-24 1:49 UTC (permalink / raw)
To: Weijie Yuan
Cc: brian m. carlson, Alexey Samsonov via GitGitGadget, git,
Alexey Samsonov, Johannes Schindelin
Weijie Yuan <wy@wyuan.org> writes:
>> We know Johannes well enough to trust that his patches were sent
>> with sufficient due diligence. So...?
>
> <xmqqzeyeujde.fsf@gitster.g>:
>> 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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-24 1:49 ` Junio C Hamano
@ 2026-08-24 12:19 ` Weijie Yuan
2026-08-24 15:33 ` Weijie Yuan
1 sibling, 0 replies; 19+ messages in thread
From: Weijie Yuan @ 2026-08-24 12:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: brian m. carlson, Alexey Samsonov via GitGitGadget, git,
Alexey Samsonov, Johannes Schindelin
On Sun, Aug 23, 2026 at 06:49:49PM -0700, Junio C Hamano wrote:
> Weijie Yuan <wy@wyuan.org> writes:
>
> >> We know Johannes well enough to trust that his patches were sent
> >> with sufficient due diligence. So...?
> >
> > <xmqqzeyeujde.fsf@gitster.g>:
> >> 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?
Apologies, and please forget it. I must be feeling dizzy.
Thanks.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-24 1:49 ` Junio C Hamano
2026-08-24 12:19 ` Weijie Yuan
@ 2026-08-24 15:33 ` Weijie Yuan
2026-08-24 16:06 ` Junio C Hamano
1 sibling, 1 reply; 19+ messages in thread
From: Weijie Yuan @ 2026-08-24 15:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: brian m. carlson, Alexey Samsonov via GitGitGadget, git,
Alexey Samsonov, Johannes Schindelin
On Sun, Aug 23, 2026 at 06:49:49PM -0700, Junio C Hamano wrote:
> Weijie Yuan <wy@wyuan.org> writes:
>
> >> We know Johannes well enough to trust that his patches were sent
> >> with sufficient due diligence. So...?
> >
> > <xmqqzeyeujde.fsf@gitster.g>:
> >> 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?
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-24 15:33 ` Weijie Yuan
@ 2026-08-24 16:06 ` Junio C Hamano
2026-08-24 16:23 ` Junio C Hamano
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Junio C Hamano @ 2026-08-24 16:06 UTC (permalink / raw)
To: Weijie Yuan
Cc: brian m. carlson, Alexey Samsonov via GitGitGadget, git,
Alexey Samsonov, Johannes Schindelin
Weijie Yuan <wy@wyuan.org> writes:
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-24 16:06 ` Junio C Hamano
@ 2026-08-24 16:23 ` Junio C Hamano
2026-08-24 16:33 ` Weijie Yuan
2026-08-24 20:25 ` Oswald Buddenhagen
2 siblings, 0 replies; 19+ messages in thread
From: Junio C Hamano @ 2026-08-24 16:23 UTC (permalink / raw)
To: Weijie Yuan
Cc: brian m. carlson, Alexey Samsonov via GitGitGadget, git,
Alexey Samsonov, Johannes Schindelin
Junio C Hamano <gitster@pobox.com> writes:
> 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).
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-24 16:06 ` Junio C Hamano
2026-08-24 16:23 ` Junio C Hamano
@ 2026-08-24 16:33 ` Weijie Yuan
2026-08-24 20:25 ` Oswald Buddenhagen
2 siblings, 0 replies; 19+ messages in thread
From: Weijie Yuan @ 2026-08-24 16:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: brian m. carlson, Alexey Samsonov via GitGitGadget, git,
Alexey Samsonov, Johannes Schindelin
> Weijie Yuan <wy@wyuan.org> writes:
>
> > 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.
> ... 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat
2026-08-24 16:06 ` Junio C Hamano
2026-08-24 16:23 ` Junio C Hamano
2026-08-24 16:33 ` Weijie Yuan
@ 2026-08-24 20:25 ` Oswald Buddenhagen
2 siblings, 0 replies; 19+ messages in thread
From: Oswald Buddenhagen @ 2026-08-24 20:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Weijie Yuan, brian m. carlson, Alexey Samsonov via GitGitGadget,
git, Alexey Samsonov, Johannes Schindelin
On Mon, Aug 24, 2026 at 09:06:21AM -0700, Junio C Hamano wrote:
>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.
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2026-08-24 20:25 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-21 14:23 [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 1/3] compat/posix: introduce utimensat(2) wrapper Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 2/3] treewide: use utimensat(2) instead of legacy utime(3p) Alexey Samsonov via GitGitGadget
2026-08-21 14:23 ` [PATCH 3/3] compat/posix: drop legacy <utime.h> header and shims Alexey Samsonov via GitGitGadget
2026-08-21 17:33 ` [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat Junio C Hamano
2026-08-22 16:03 ` brian m. carlson
2026-08-22 17:59 ` Junio C Hamano
2026-08-22 21:15 ` brian m. carlson
2026-08-23 15:23 ` Junio C Hamano
2026-08-23 13:26 ` Weijie Yuan
2026-08-23 15:26 ` Junio C Hamano
2026-08-23 15:45 ` Weijie Yuan
2026-08-24 1:49 ` Junio C Hamano
2026-08-24 12:19 ` Weijie Yuan
2026-08-24 15:33 ` Weijie Yuan
2026-08-24 16:06 ` Junio C Hamano
2026-08-24 16:23 ` Junio C Hamano
2026-08-24 16:33 ` Weijie Yuan
2026-08-24 20:25 ` Oswald Buddenhagen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox