Volume XXII, number 279Tuesday, October 6, 2026Latest message 11 minutes ago

The Git List

News and archive of git@vger.kernel.org, since April 2005

patch, 3 partstreewide: migrate from legacy utime.h to utimensat

19 messages between Aug 21, 2026 and Aug 24, 2026, from Alexey Samsonov via GitGitGadget, Junio C Hamano, brian m. carlson, Weijie Yuan, Oswald Buddenhagen.

Plain Markdown or JSON for tools and agents. Diffs are folded; open one to read it.

Alexey Samsonov via GitGitGadgetAug 21, 2026, 14:23 UTC on lore

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
Alexey Samsonov via GitGitGadgetAug 21, 2026, 14:23 UTC in reply to Alexey Samsonov via GitGitGadget on lore

[PATCH 1/3] compat/posix: introduce utimensat(2) wrapper

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
Show changes to 8 files +127 −9

Makefile, compat/mingw-posix.h, compat/mingw.c, compat/posix.h, compat/utimensat.c, configure.ac, contrib/buildsystems/CMakeLists.txt, meson.build

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(&times[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(&times[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
Alexey Samsonov via GitGitGadgetAug 21, 2026, 14:23 UTC in reply to Alexey Samsonov via GitGitGadget on lore

[PATCH 2/3] treewide: use utimensat(2) instead of legacy utime(3p)

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(-)
Show changes to 8 files +52 −44

builtin/pack-objects.c, commit-graph.c, copy.c, object-file.c, odb/source-loose.c, odb/source-packed.c, rerere.c, t/helper/test-chmtime.c

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, &times) < 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;
+		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;
+		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
Alexey Samsonov via GitGitGadgetAug 21, 2026, 14:23 UTC in reply to Alexey Samsonov via GitGitGadget on lore

[PATCH 3/3] compat/posix: drop legacy <utime.h> header and shims

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
Show changes to 7 files +0 −56

compat/mingw-posix.h, compat/mingw.c, compat/posix.h, compat/vcbuild/include/sys/utime.h, compat/vcbuild/include/utime.h, t/helper/test-chmtime.c, t/t4051/includes.c

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
Junio C HamanoAug 21, 2026, 17:33 UTC in reply to Alexey Samsonov via GitGitGadget on lore

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

"Alexey Samsonov via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 17 quoted lines
> 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.

brian m. carlsonAug 22, 2026, 16:03 UTC in reply to Alexey Samsonov via GitGitGadget on lore

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

On 2026-08-21 at 14:23:20, Alexey Samsonov via GitGitGadget wrote:
Show 13 quoted lines
> 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.

Show 11 quoted 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
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Junio C HamanoAug 22, 2026, 17:59 UTC in reply to brian m. carlson on lore

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

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 17 quoted lines
> 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".

brian m. carlsonAug 22, 2026, 21:15 UTC in reply to Junio C Hamano on lore

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

On 2026-08-22 at 17:59:09, Junio C Hamano wrote:
Show 24 quoted lines
> "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.

Show 6 quoted 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.

Show 5 quoted 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.

Show 11 quoted 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.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Weijie YuanAug 23, 2026, 13:26 UTC in reply to Junio C Hamano on lore

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

[+cc Johannes Schindelin]
On Sat, Aug 22, 2026 at 10:59:09AM -0700, Junio C Hamano wrote:
Show 37 quoted lines
> "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)
Show 6 quoted 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/aorxVo_6_U1ceaKm@wyuan.org/ [2] https://lore.kernel.org/all/CAHk-=wgbGarE7Ozw4VG6oUKDj9pk-8DRoDiX00bo1MwEMm9UWQ@mail.gmail.com/

Junio C HamanoAug 23, 2026, 15:23 UTC in reply to brian m. carlson on lore

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

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 5 quoted lines
> 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" ;-).

Show 7 quoted 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.

> 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.
Junio C HamanoAug 23, 2026, 15:26 UTC in reply to Weijie Yuan on lore

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

Weijie Yuan <wy@wyuan.org> writes:
Show 5 quoted lines
> 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...?

Weijie YuanAug 23, 2026, 15:45 UTC in reply to Junio C Hamano on lore

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

On Sun, Aug 23, 2026 at 08:26:40AM -0700, Junio C Hamano wrote:
Show 10 quoted lines
> 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>:
Show 5 quoted 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.
Junio C HamanoAug 24, 2026, 01:49 UTC in reply to Weijie Yuan on lore

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

Weijie Yuan <wy@wyuan.org> writes:
Show 12 quoted lines
>> 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?

Weijie YuanAug 24, 2026, 12:19 UTC in reply to Junio C Hamano on lore

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

On Sun, Aug 23, 2026 at 06:49:49PM -0700, Junio C Hamano wrote:
Show 18 quoted lines
> 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.
Weijie YuanAug 24, 2026, 15:33 UTC in reply to Junio C Hamano on lore

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

On Sun, Aug 23, 2026 at 06:49:49PM -0700, Junio C Hamano wrote:
Show 18 quoted lines
> 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

Junio C HamanoAug 24, 2026, 16:06 UTC in reply to Weijie Yuan on lore

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

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.

Junio C HamanoAug 24, 2026, 16:23 UTC in reply to Junio C Hamano on lore

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

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).

Weijie YuanAug 24, 2026, 16:33 UTC in reply to Junio C Hamano on lore

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

Show 23 quoted lines
> 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.
Oswald BuddenhagenAug 24, 2026, 20:25 UTC in reply to Junio C Hamano on lore

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

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.

Back to recent threads