Skip to contentSkip to conversation

treewide: migrate from legacy utime.h to utimensat

PATCH In review Alexey Samsonov via GitGitGadget 5 participants 19 messages Aug 21 – Aug 24

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover treewide: migrate from legacy utime.h to utimensat

utime() function for setting access/modification time for files (and a corresponding <utime.h> header) have been officially removed from POSIX starting from POSIX.1-2024. While existing system library implementations still provide this function for compatibility reasons, its implementation may be removed in the future, or otherwise degrade over time. Some newer libc implementations (e.g. LLVM-libc, currently under development) don't provide utime() function at all.

This PR switches the git codebase to recommended alternative: utimensat() POSIX function (which supports nanosecond-level precision) from <fcntl.h>, and, as a possible fallback for older systems compatibility, utimes() function from <sys/stat.h>. It also provides the corresponding MinGW wrapper.

The alternative is to unconditionally use utimes() where possible, but given that utimensat is available in glibc starting from 2007, and on BSD systems since 2012 or so, it makes sense to use the newer variant by default.

No behavior changes is intended or expected (except for Git explicitly passing nanosecond-precision timestamps to kernel, where previously only second-level precision was used).

This change is generated by Gemini Flash from Antigravity, but all the code has been manually verified by me, and, where applicable, adjusted to match the existing behavior as closely as possible.

Alexey Samsonov (3):
compat/posix: introduce utimensat(2) wrapper
treewide: use utimensat(2) instead of legacy utime(3p) compat/posix: drop legacy <utime.h> header and shims

 Makefile                            |  6 +++++
 builtin/pack-objects.c              | 12 +++++----
 commit-graph.c                      | 17 +++++--------
 compat/mingw-posix.h                |  4 +--
 compat/mingw.c                      | 36 ++++++++++++++++++++------
 compat/posix.h                      | 22 +++++++++++++++-
 compat/utimensat.c                  | 39 +++++++++++++++++++++++++++++
 compat/vcbuild/include/sys/utime.h  | 34 -------------------------
 compat/vcbuild/include/utime.h      |  1 -
 configure.ac                        |  6 +++++
 contrib/buildsystems/CMakeLists.txt |  8 ++++--
 copy.c                              | 10 +++++---
 meson.build                         |  2 ++
 object-file.c                       | 12 +++++----
 odb/source-loose.c                  | 10 ++++----
 odb/source-packed.c                 | 12 +++++----
 rerere.c                            |  4 +--
 t/helper/test-chmtime.c             | 20 +++++++++------
 t/t4051/includes.c                  |  1 -
 19 files changed, 163 insertions(+), 93 deletions(-)
 create mode 100644 compat/utimensat.c
 delete mode 100644 compat/vcbuild/include/sys/utime.h
 delete mode 100644 compat/vcbuild/include/utime.h

base-commit: dea0ea3582e6980ddbc1173cc8e3e9f9db91cde0
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2209%2Fvonosmas%2Fdrop-utime-h-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2209/vonosmas/drop-utime-h-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2209

Signature · 1 line
gitgitgadget
#1 lore raw

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

From: Alexey Samsonov <[email protected]>

In POSIX.1-2008, utime(3p) was marked as obsolescent in favor of utimensat(2) and futimens(2). In the recent POSIX.1-2024 (Issue 8) specification, <utime.h> and utime(3p) were officially removed.

utimensat(2) operates on struct timespec rather than the second-only struct utimbuf, allowing sub-second timestamp updates while also providing support for UTIME_NOW and UTIME_OMIT flags to selectively update or preserve individual access and modification timestamps.

Introduce a compatibility layer for utimensat(2):
- Provide fallback definitions for AT_FDCWD, UTIME_NOW, and UTIME_OMIT in case the system headers lack them.
- Introduce ST_ATIME_NSEC(st) to complement ST_MTIME_NSEC(st) and ST_CTIME_NSEC(st).
- Implement git_utimensat() in compat/utimensat.c as a fallback using utimes(2) on platforms that define NO_UTIMENSAT.
- Implement mingw_utimensat() in compat/mingw.c converting struct timespec to Windows FILETIME with 100ns precision.
- Wire up NO_UTIMENSAT support in Makefile, meson.build, contrib/buildsystems/CMakeLists.txt, and configure.ac.

Subsequent commits will migrate callers across the codebase to utimensat(2) and drop the legacy <utime.h> header.

---
 Makefile                            |  6 ++++
 compat/mingw-posix.h                |  2 ++
 compat/mingw.c                      | 52 +++++++++++++++++++++++++----
 compat/posix.h                      | 21 ++++++++++++
 compat/utimensat.c                  | 39 ++++++++++++++++++++++
 configure.ac                        |  6 ++++
 contrib/buildsystems/CMakeLists.txt |  8 +++--
 meson.build                         |  2 ++
 8 files changed, 127 insertions(+), 9 deletions(-)
 create mode 100644 compat/utimensat.c
Makefile +6 -0
index d4b775953d..64909d48b2 100644
@@ -70,6 +70,8 @@ include shared.mak
 #
 # Define NO_MKDTEMP if you don't have mkdtemp in the C library.
 #
+# Define NO_UTIMENSAT if you don't have utimensat.
+#
 # Define MKDIR_WO_TRAILING_SLASH if your mkdir() can't deal with trailing slash.
 #
 # Define NO_GECOS_IN_PWENT if you don't have pw_gecos in struct passwd
@@ -2049,6 +2051,10 @@ ifdef NO_WRITEV
 	COMPAT_CFLAGS += -DNO_WRITEV
 	COMPAT_OBJS += compat/writev.o
 endif
+ifdef NO_UTIMENSAT
+	COMPAT_CFLAGS += -DNO_UTIMENSAT
+	COMPAT_OBJS += compat/utimensat.o
+endif
 ifdef NO_FAST_WORKING_DIRECTORY
 	BASIC_CFLAGS += -DNO_FAST_WORKING_DIRECTORY
 endif
compat/mingw-posix.h +2 -0
index 2d989fd762..aab91d76db 100644
@@ -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
compat/mingw.c +45 -7

87 lines not on this page · raw message

compat/posix.h +21 -0
index 71cc731620..3cac1751aa 100644
@@ -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
compat/utimensat.c new file +39 -0
new file mode 100644
index 0000000000..e4c8e8d0b6
@@ -0,0 +1,39 @@
+#include "../git-compat-util.h"
+
+int git_utimensat(int fd, const char *path, const struct timespec times[2], int flag)
+{
+	struct timeval tv[2];
+	struct timeval *tvp = NULL;
+
+	if (fd != AT_FDCWD) {
+		errno = ENOSYS;
+		return -1;
+	}
+
+	if (flag) {
+		errno = ENOSYS;
+		return -1;
+	}
+
+	if (times) {
+		for (int i = 0; i < 2; i++) {
+			if (times[i].tv_nsec == UTIME_NOW) {
+				struct timeval now;
+				gettimeofday(&now, NULL);
+				tv[i] = now;
+			} else if (times[i].tv_nsec == UTIME_OMIT) {
+				struct stat st;
+				if (stat(path, &st) < 0)
+					return -1;
+				tv[i].tv_sec = (i == 0) ? st.st_atime : st.st_mtime;
+				tv[i].tv_usec = (i == 0) ? ST_ATIME_NSEC(st) / 1000 : ST_MTIME_NSEC(st) / 1000;
+			} else {
+				tv[i].tv_sec = times[i].tv_sec;
+				tv[i].tv_usec = times[i].tv_nsec / 1000;
+			}
+		}
+		tvp = tv;
+	}
+
+	return utimes(path, tvp);
+}
configure.ac +6 -0
index cfb50112bf..a37a53f5b5 100644
@@ -1146,6 +1146,12 @@ GIT_CHECK_FUNC(mkdtemp,
 [NO_MKDTEMP=YesPlease])
 GIT_CONF_SUBST([NO_MKDTEMP])
 #
+# Define NO_UTIMENSAT if you don't have utimensat in the C library.
+GIT_CHECK_FUNC(utimensat,
+[NO_UTIMENSAT=],
+[NO_UTIMENSAT=YesPlease])
+GIT_CONF_SUBST([NO_UTIMENSAT])
+#
 # Define NO_INITGROUPS if you don't have initgroups in the C library.
 GIT_CHECK_FUNC(initgroups,
 [NO_INITGROUPS=],
contrib/buildsystems/CMakeLists.txt +6 -2
index 8f56203f34..bb1d96802d 100644
@@ -380,9 +380,9 @@ set(function_checks
 	strcasestr memmem strlcpy strtoimax strtoumax strtoull
 	setenv mkdtemp poll pread memmem writev)
 
-#unsetenv,hstrerror are incompatible with windows build
+#unsetenv,hstrerror,utimensat are incompatible with windows build (provided by compat/mingw.c)
 if(NOT WIN32)
-	list(APPEND function_checks unsetenv hstrerror)
+	list(APPEND function_checks unsetenv hstrerror utimensat)
 endif()
 
 foreach(f ${function_checks})
@@ -428,6 +428,10 @@ if(NOT HAVE_WRITEV)
 endif()
 
 if(NOT WIN32)
+	if(NOT HAVE_UTIMENSAT)
+		list(APPEND compat_SOURCES compat/utimensat.c)
+	endif()
+
 	if(NOT HAVE_UNSETENV)
 		list(APPEND compat_SOURCES compat/unsetenv.c)
 	endif()
meson.build +2 -0
index d86f2acd2b..a98f63a46c 100644
@@ -1475,6 +1475,8 @@ else
     'unsetenv' : ['unsetenv.c'],
     # provided by compat/mingw.c.
     'getpagesize' : [],
+    # provided by compat/mingw.c.
+    'utimensat' : ['utimensat.c'],
   }
 
   if get_option('b_sanitize').contains('address') or get_option('b_sanitize').contains('leak')
Signature · 1 line
gitgitgadget
#2 lore raw

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

In reply to Alexey Samsonov via GitGitGadget

From: Alexey Samsonov <[email protected]>

Now that a compatibility wrapper for utimensat(2) has been introduced, migrate all call sites across the codebase to use utimensat(2) instead of the legacy utime(3p) interface:

- In commit-graph.c, use utimensat(2) with UTIME_OMIT and the computed timestamp now to bump the commit-graph modification time consistently across all files without needing an extra stat(2) call to preserve atime.
- In copy.c, use utimensat(2) to copy full sub-second access and modification timestamps from the source file.
- In odb/source-packed.c, odb/source-loose.c, and object-file.c, use utimensat(2) with struct timespec to freshen file timestamps.
- In builtin/pack-objects.c, update the pack timestamp with utimensat(2).
- In rerere.c, touch the postimage file with utimensat(2) passing NULL to set both atime and mtime to current time.
- In t/helper/test-chmtime.c, update file modification times using utimensat(2).

---
 builtin/pack-objects.c  | 12 +++++++-----
 commit-graph.c          | 17 ++++++-----------
 copy.c                  | 10 ++++++----
 object-file.c           | 12 +++++++-----
 odb/source-loose.c      | 10 +++++-----
 odb/source-packed.c     | 12 +++++++-----
 rerere.c                |  4 ++--
 t/helper/test-chmtime.c | 19 ++++++++++++-------
 8 files changed, 52 insertions(+), 44 deletions(-)
builtin/pack-objects.c +7 -5
index 1ec5b6f206..35bdbc2b6a 100644
@@ -1438,11 +1438,13 @@ static void write_pack_file(void)
 			} else if (!last_mtime) {
 				last_mtime = st.st_mtime;
 			} else {
-				struct utimbuf utb;
-				utb.actime = st.st_atime;
-				utb.modtime = --last_mtime;
-				if (utime(pack_tmp_name, &utb) < 0)
-					warning_errno(_("failed utime() on %s"), pack_tmp_name);
+				struct timespec times[2];
+				times[0].tv_sec = st.st_atime;
+				times[0].tv_nsec = ST_ATIME_NSEC(st);
+				times[1].tv_sec = --last_mtime;
+				times[1].tv_nsec = 0;
+				if (utimensat(AT_FDCWD, pack_tmp_name, times, 0) < 0)
+					warning_errno(_("failed utimensat() on %s"), pack_tmp_name);
 			}
 
 			strbuf_addf(&tmpname, "%s-%s.", base_name,
commit-graph.c +6 -11
index 49e8f63930..08bbba3d98 100644
@@ -2484,18 +2484,13 @@ static void mark_commit_graphs(struct write_commit_graph_context *ctx)
 {
 	uint32_t i;
 	time_t now = time(NULL);
+	struct timespec times[2] = {
+		{ .tv_nsec = UTIME_OMIT },
+		{ .tv_sec = now, .tv_nsec = 0 },
+	};
 
-	for (i = ctx->num_commit_graphs_after - 1; i < ctx->num_commit_graphs_before; i++) {
-		struct stat st;
-		struct utimbuf updated_time;
-
-		if (stat(ctx->commit_graph_filenames_before[i], &st) < 0)
-			continue;
-
-		updated_time.actime = st.st_atime;
-		updated_time.modtime = now;
-		utime(ctx->commit_graph_filenames_before[i], &updated_time);
-	}
+	for (i = ctx->num_commit_graphs_after - 1; i < ctx->num_commit_graphs_before; i++)
+		utimensat(AT_FDCWD, ctx->commit_graph_filenames_before[i], times, 0);
 }
 
 static void expire_commit_graphs(struct write_commit_graph_context *ctx)
copy.c +6 -4
index 6074132050..39673f7829 100644
@@ -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;
 }
object-file.c +7 -5
index ec35c318bc..5e4ccb36d5 100644
@@ -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);
 }
 
 /*
odb/source-loose.c +5 -5
index ef0e919277..1fdaa9f88f 100644
@@ -807,14 +807,14 @@ static int write_loose_object(struct odb_source_loose *loose,
 	close_loose_object(loose, fd, tmp_file.buf);
 
 	if (mtime) {
-		struct utimbuf utb = {
-			.actime = *mtime,
-			.modtime = *mtime,
+		struct timespec times[2] = {
+			{ .tv_sec = *mtime },
+			{ .tv_sec = *mtime },
 		};
 
-		if (utime(tmp_file.buf, &utb) < 0 &&
+		if (utimensat(AT_FDCWD, tmp_file.buf, times, 0) < 0 &&
 		    !(flags & ODB_WRITE_OBJECT_SILENT))
-			warning_errno(_("failed utime() on %s"), tmp_file.buf);
+			warning_errno(_("failed utimensat() on %s"), tmp_file.buf);
 	}
 
 	return finalize_object_file_flags(loose->base.odb->repo, tmp_file.buf, filename.buf,
odb/source-packed.c +7 -5
index 0890704e76..64871ff8da 100644
@@ -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;
 
rerere.c +2 -2
index 3d3bd0db16..b64771f57f 100644
@@ -658,8 +658,8 @@ static int merge(struct index_state *istate, const struct rerere_id *id, const c
 	 * A successful replay of recorded resolution.
 	 * Mark that "postimage" was used to help gc.
 	 */
-	if (utime(rerere_path(&buf, id, "postimage"), NULL) < 0)
-		warning_errno(_("failed utime() on '%s'"),
+	if (utimensat(AT_FDCWD, rerere_path(&buf, id, "postimage"), NULL, 0) < 0)
+		warning_errno(_("failed utimensat() on '%s'"),
 			      rerere_path(&buf, id, "postimage"));
 
 	/* Update "path" with the resolution */
t/helper/test-chmtime.c +12 -7
index 0e5538833a..a9e6eb78b8 100644
@@ -105,7 +105,8 @@ int cmd__chmtime(int argc, const char **argv)
 
 	for (; i < argc; i++) {
 		struct stat sb;
-		struct utimbuf utb;
+		struct timespec times[2];
+		int64_t mtime_sec;
 		uintmax_t mtime;
 
 		if (stat(argv[i], &sb) < 0) {
@@ -123,22 +124,26 @@ int cmd__chmtime(int argc, const char **argv)
 		}
 #endif
 
-		utb.actime = sb.st_atime;
-		utb.modtime = set_eq ? set_time : sb.st_mtime + set_time;
+		mtime_sec = set_eq ? set_time : sb.st_mtime + set_time;
 
-		mtime = utb.modtime < 0 ? 0: utb.modtime;
+		times[0].tv_sec = sb.st_atime;
+		times[0].tv_nsec = ST_ATIME_NSEC(sb);
+		times[1].tv_sec = mtime_sec;
+		times[1].tv_nsec = 0;
+
+		mtime = mtime_sec < 0 ? 0 : mtime_sec;
 		if (get) {
 			printf("%"PRIuMAX"\n", mtime);
 		} else if (verbose) {
 			printf("%"PRIuMAX"\t%s\n", mtime, argv[i]);
 		}
 
-		if (utb.modtime != sb.st_mtime && utime(argv[i], &utb) < 0) {
+		if (mtime_sec != sb.st_mtime && utimensat(AT_FDCWD, argv[i], times, 0) < 0) {
 #ifdef GIT_WINDOWS_NATIVE
 			if (S_ISDIR(sb.st_mode)) {
 				/*
-				 * NEEDSWORK: The Windows version of `utime()`
-				 * (aka `mingw_utime()`) does not correctly
+				 * NEEDSWORK: The Windows version of `utimensat()`
+				 * (aka `mingw_utimensat()`) does not correctly
 				 * handle directory arguments, since it uses
 				 * `_wopen()`.  Ignore it for now since this
 				 * is just a test.
Signature · 1 line
gitgitgadget
#3 lore raw

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

In reply to Alexey Samsonov via GitGitGadget

From: Alexey Samsonov <[email protected]>

With all callers across the codebase now converted to utimensat(2), we no longer need to include the legacy <utime.h> header in compat/posix.h.

Remove #include <utime.h> from compat/posix.h and test fixtures, remove mingw_utime() from compat/mingw.c, and delete the legacy header shims in compat/vcbuild/include/.

---
 compat/mingw-posix.h               |  2 --
 compat/mingw.c                     | 16 --------------
 compat/posix.h                     |  1 -
 compat/vcbuild/include/sys/utime.h | 34 ------------------------------
 compat/vcbuild/include/utime.h     |  1 -
 t/helper/test-chmtime.c            |  1 -
 t/t4051/includes.c                 |  1 -
 7 files changed, 56 deletions(-)
 delete mode 100644 compat/vcbuild/include/sys/utime.h
 delete mode 100644 compat/vcbuild/include/utime.h
compat/mingw-posix.h +0 -2
index aab91d76db..286ca24002 100644
@@ -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,
compat/mingw.c +0 -16
index d09a976191..e2ec44fdd2 100644
@@ -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)
compat/posix.h +0 -1
index 3cac1751aa..435ed90f56 100644
@@ -123,7 +123,6 @@
 #include <signal.h>
 #include <assert.h>
 #include <regex.h>
-#include <utime.h>
 #include <syslog.h>
 #if !defined(NO_POLL_H)
 #include <poll.h>
compat/vcbuild/include/sys/utime.h deleted +0 -34
deleted file mode 100644
index 582589c70a..0000000000
@@ -1,34 +0,0 @@
-#ifndef	_UTIME_H_
-#define	_UTIME_H_
-/*
- * UTIME.H
- * This file has no copyright assigned and is placed in the Public Domain.
- * This file is a part of the mingw-runtime package.
- *
- * The mingw-runtime package and its code is distributed in the hope that it
- * will be useful but WITHOUT ANY WARRANTY.  ALL WARRANTIES, EXPRESSED OR
- * IMPLIED ARE HEREBY DISCLAIMED.  This includes but is not limited to
- * warranties of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
- *
- * You are free to use this package and its code without limitation.
- */
-
-/*
- * Structure used by _utime function.
- */
-struct _utimbuf
-{
-	time_t	actime;		/* Access time */
-	time_t	modtime;	/* Modification time */
-};
-
-#ifndef	_NO_OLDNAMES
-/* NOTE: Must be the same as _utimbuf above. */
-struct utimbuf
-{
-	time_t	actime;
-	time_t	modtime;
-};
-#endif	/* Not _NO_OLDNAMES */
-
-#endif
compat/vcbuild/include/utime.h deleted +0 -1
deleted file mode 100644
index 8285f38fde..0000000000
@@ -1 +0,0 @@
-#include <sys/utime.h>
t/helper/test-chmtime.c +0 -1
index a9e6eb78b8..295f55cf47 100644
@@ -38,7 +38,6 @@
  */
 #include "test-tool.h"
 #include "git-compat-util.h"
-#include <utime.h>
 
 static const char usage_str[] =
 	"(-v|--verbose|-g|--get) (+|=|=+|=-|-)<seconds> <file>...";
t/t4051/includes.c +0 -1
index efc68f8bf6..4861f6657b 100644
@@ -15,6 +15,5 @@
 #include <signal.h>
 #include <assert.h>
 #include <regex.h>
-#include <utime.h>
 #include <syslog.h>
 #include <End.h>
Signature · 1 line
gitgitgadget
#4 lore raw
In reply to Alexey Samsonov via GitGitGadget
Quoted 14 lines · Alexey Samsonov via GitGitGadget

utime() function for setting access/modification time for files (and a corresponding <utime.h> header) have been officially removed from POSIX starting from POSIX.1-2024. While existing system library implementations still provide this function for compatibility reasons, its implementation may be removed in the future, or otherwise degrade over time. Some newer libc implementations (e.g. LLVM-libc, currently under development) don't 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.

Quoted 3 lines

The alternative is to unconditionally use utimes() where possible, but given that utimensat is available in glibc starting from 2007, and on BSD systems since 2012 or so, it makes sense to use the newer variant by default.

I hear that Apple has supported it since macOS 10.13 High Sierra, which came out in 2017 and reached EOL in 2020, so we should be safe there as well.

#5 lore raw
In reply to Alexey Samsonov via GitGitGadget
Quoted 8 lines · Alexey Samsonov via GitGitGadget

utime() function for setting access/modification time for files (and a corresponding <utime.h> header) have been officially removed from POSIX starting from POSIX.1-2024. While existing system library implementations still provide this function for compatibility reasons, its implementation may be removed in the future, or otherwise degrade over time. Some newer libc implementations (e.g. LLVM-libc, currently under development) don't provide utime() function at all.

Quoted 5 lines

This PR switches the git codebase to recommended alternative: utimensat() POSIX function (which supports nanosecond-level precision) from <fcntl.h>, and, as a possible fallback for older systems compatibility, utimes() function from <sys/stat.h>. It also provides the corresponding MinGW wrapper.

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

Quoted 11 lines

The alternative is to unconditionally use utimes() where possible, but given that utimensat is available in glibc starting from 2007, and on BSD systems since 2012 or so, it makes sense to use the newer variant by default.

No behavior changes is intended or expected (except for Git explicitly passing nanosecond-precision timestamps to kernel, where previously only second-level precision was used).

This change is generated by Gemini Flash from Antigravity, but all the code has been manually verified by me, and, where applicable, adjusted to match the existing behavior as closely as possible.

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

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

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

[0] https://git-scm.com/docs/SubmittingPatches#ai

Signature · 2 lines
brian m. carlson (they/them)
Toronto, Ontario, CA
#6 lore raw
Quoted 13 lines · brian m. carlson
Quoted 3 lines · Alexey Samsonov via GitGitGadget

This change is generated by Gemini Flash from Antigravity, but all the code has been manually verified by me, and, where applicable, adjusted to match the existing behavior as closely as possible.

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

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

Quoted 4 lines

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

[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".

#7 lore raw
Quoted 18 lines · Junio C Hamano
Quoted 16 lines · brian m. carlson
Quoted 3 lines · Alexey Samsonov via GitGitGadget

This change is generated by Gemini Flash from Antigravity, but all the code has been manually verified by me, and, where applicable, adjusted to match the existing behavior as closely as possible.

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

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

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

Quoted 6 lines
Quoted 1 line

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

Quoted 6 lines

I think that is a much more prudent attitude than being cavalier about legal issues. I used to think, "Hey, the person claims in the DCO that the code is appropriately licensed, so if it turns out to be a false claim later, that is his or her problem, not ours."

But that is not how things work.

It's my understanding that in many places there's a difference between knowingly doing something and doing something without knowledge. For example, Canada's Copyright Act uses the text, "that the person knows or should have known infringes copyright".

So we do have more of a legal problem if we knowingly distribute code that infringes copyright or which we suspect may do so.

Quoted 5 lines

If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.

Yes, that's true. We still have the fallout and issues in terms of project management to deal with, but fewer legal problems.

Quoted 11 lines

Stepping back a bit, though, is the situation really all that different between a relatively new author who discloses their use of AI and another author similarly unknown to us who claims it is all their own work? Either way, if the code turns out to be unusable, we would still be on the hook for participating in the infringement and would bear the cost of ripping it out.

What worries me a bit is that there may not be much difference between "you said that you relayed AI output, so we won't talk to you" and "we do not know you well enough to trust you, so we won't talk to you".

If somebody comes to our project and lies to us about the provenance of their work, that's very serious. Saying, "I wrote this with AI," when we don't allow AI is being honest and ethical and disclosing relevant details to the project. It may be that we can't accept their code for that reason, but they have participated in the project in good faith. We could certainly accept other patches from such a person written without AI.

But if a contributor misleads us about the origin of their code, whether it came from AI or was taken without credit from another project, then they're not at all acting in good faith and we will likely not allow them to continue to contribute to the project. Moreover, they will also be unwelcome in most other projects as well because they'll be viewed as dishonest.

That doesn't affect whether we end up having negative consequences from distributing that code, true. But at some point, we have to trust that most people are honest or our community and society break down.

Signature · 2 lines
brian m. carlson (they/them)
Toronto, Ontario, CA
#8 lore raw
Quoted 5 lines · brian m. carlson
Quoted 4 lines · Junio C Hamano
Quoted 2 lines · brian m. carlson

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

More on this a bit later...

Quoted 2 lines

So we do have more of a legal problem if we knowingly distribute code that infringes copyright or which we suspect may do so.

Projects like the Linux kernel ask you to disclose your use of AI (and have other requirements on your use), but I haven't read exactly why they want it. I wish they instead said, "We do not want to be blamed for knowingly infringing. While we do not particularly encourage you to use AI, if you use one, do not tell us" ;-).

Quoted 7 lines

If somebody comes to our project and lies to us about the provenance of their work, that's very serious. Saying, "I wrote this with AI," when we don't allow AI is being honest and ethical and disclosing relevant details to the project. It may be that we can't accept their code for that reason, but they have participated in the project in good faith. We could certainly accept other patches from such a person written without AI.

But that contradicts what you yourself did, doesn't it? An honest developer who discloses their use of AI admits that their eyes are already contaminated by AI output, because they did not avoid being influenced as you did. So are they unwelcome now?

Stepping back a bit, even before the AI era, a human developer may have seen code elsewhere that they are not allowed to include in a particular project. Learning from what others did is the nature of our work, and it is inevitable. Is it reasonable for BSD-only projects to declare that those who are familiar with constructs that appear in Git code after working on it are unwelcome, because their contributions may be contaminated by what they have seen in a GPLed project?

I very much appreciate that you are treading very cautiously on the safer side, but I hope that the actual balance lies on a somewhat more practical side that trusts humans.

Quoted 3 lines

That doesn't affect whether we end up having negative consequences from distributing that code, true. But at some point, we have to trust that most people are honest or our community and society break down.

True. True.

Thanks.

#9 lore raw
In reply to Junio C Hamano

[+cc Johannes Schindelin]

Quoted 30 lines · Junio C Hamano
Quoted 13 lines · brian m. carlson
Quoted 3 lines · Alexey Samsonov via GitGitGadget

This change is generated by Gemini Flash from Antigravity, but all the code has been manually verified by me, and, where applicable, adjusted to match the existing behavior as closely as possible.

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

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

Quoted 4 lines

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

[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."

Quoted 7 lines

But that is not how things work.

If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.

Sorry to interject here, but I seem to remember that dscho already has a few commits with an Assisted-by trailer that have made it into master. I´m not entirely sure what kind of assistance he received either, but as you suggest, it seems better to mention this here sooner rather than later.

(I also mentioned this part here [1], with full respect to Johannes)

Quoted 11 lines

Stepping back a bit, though, is the situation really all that different between a relatively new author who discloses their use of AI and another author similarly unknown to us who claims it is all their own work? Either way, if the code turns out to be unusable, we would still be on the hook for participating in the infringement and would bear the cost of ripping it out.

What worries me a bit is that there may not be much difference between "you said that you relayed AI output, so we won't talk to you" and "we do not know you well enough to trust you, so we won't talk to you".

But I think that, from Linus's point of view, the chain of trust matters more than whether AI was used in the first place:

| So AI giveth, and AI taketh away. But the basic issue shouldn't be AI | per se, it should be that notion of "trust". [2]

Of course, I also understand that the Git community doesn't need to completely follow the rules from kernel community.

Thanks.

[1] https://lore.kernel.org/git/[email protected]/
[2] https://lore.kernel.org/all/CAHk-=wgbGarE7Ozw4VG6oUKDj9pk-8DRoDiX00bo1MwEMm9UWQ@mail.gmail.com/

#10 lore raw
Quoted 5 lines · Weijie Yuan

Sorry to interject here, but I seem to remember that dscho already has a few commits with an Assisted-by trailer that have made it into master. I´m not entirely sure what kind of assistance he received either, but as you suggest, it seems better to mention this here sooner rather than later.

We know Johannes well enough to trust that his patches were sent with sufficient due diligence. So...?

#11 lore raw
Quoted 10 lines · Junio C Hamano
Quoted 5 lines · Weijie Yuan

Sorry to interject here, but I seem to remember that dscho already has a few commits with an Assisted-by trailer that have made it into master. I´m not entirely sure what kind of assistance he received either, but as you suggest, it seems better to mention this here sooner rather than later.

We know Johannes well enough to trust that his patches were sent with sufficient due diligence. So...?

<[email protected]>:

Quoted 5 lines

If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.

What I meant is that you said we should be wary of content that might carry legal risks, if I understand correctly. And as far as I remember, Johannes is the only person recently who has proactively disclosed that his patches were AI-assisted. I appreciate that disclosure, so I was simply pointing it out. Of course, I have no doubt about the quality of his patches.

So what I mean is that we have already had cases where people voluntarily disclosed their use of AI, but there did not seem to be much discussion about it at the time. This time, Brian brought the issue up for discussion, and I really appreciate both of you doing so.

Thanks.

#12 lore raw
Quoted 4 lines · Weijie Yuan
Quoted 2 lines

We know Johannes well enough to trust that his patches were sent with sufficient due diligence. So...?

<[email protected]>:

Quoted 8 lines
Quoted 5 lines

If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.

What I meant is that you said we should be wary of content that might carry legal risks,...

I am not sure what your point is. Is there any part in "we trust Dscho well enough to trust that he sent them with sufficient due diligence" that was hard for you to understand?

#13 lore raw
Quoted 12 lines · Junio C Hamano
Quoted 10 lines · Weijie Yuan
Quoted 2 lines

We know Johannes well enough to trust that his patches were sent with sufficient due diligence. So...?

<[email protected]>:

Quoted 5 lines

If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.

Quoted 6 lines
Quoted 2 lines

What I meant is that you said we should be wary of content that might carry legal risks,...

I am not sure what your point is. Is there any part in "we trust Dscho well enough to trust that he sent them with sufficient due diligence" that was hard for you to understand?

Apologies, and please forget it. I must be feeling dizzy.

Thanks.

#14 lore raw
In reply to Junio C Hamano
Quoted 12 lines · Junio C Hamano
Quoted 10 lines · Weijie Yuan
Quoted 2 lines

We know Johannes well enough to trust that his patches were sent with sufficient due diligence. So...?

<[email protected]>:

Quoted 5 lines

If work submitted under a DCO later turns out to be based on something we cannot legally use, the submitter may of course be in trouble, but we would also need to bear the cost of ripping it out; the later we discover the problem, the more substantial the effort necessary to deal with the fallout will be.

Quoted 6 lines
Quoted 2 lines

What I meant is that you said we should be wary of content that might carry legal risks,...

I am not sure what your point is. Is there any part in "we trust Dscho well enough to trust that he sent them with sufficient due diligence" that was hard for you to understand?

Sorry, I think I failed to make my actual question clear in my previous replies.

I do understand, and agree with, your point that you trust Johannes to have submitted his patches with sufficient due diligence. I was not trying to question Johannes or your trust in him.

What I was trying to understand is how that fits with the particular DCO concern being discussed here.

You pointed out that if something submitted under the DCO later turns out to be based on material we cannot legally use, the project also bears the cost of removing it, and that the fallout becomes worse the later such a problem is discovered.

As I understand brian's concern, if a significant amount of a contribution is generated by an AI tool, there may be uncertainty over whether the submitter can make the DCO certification with sufficient confidence.

That is why Johannes's existing commits with an Assisted-by trailer came to mind. I am not claiming that those commits necessarily contain AI-generated content of the kind brian is concerned about; I do not know what the assistance actually consisted of.

But if the disclosed assistance did involve generated content of that kind, wouldn't the same DCO question arise? And if we do not know whether it did, isn't that the sort of question that, following your point above, would be better clarified sooner rather than later?

At the same time, I can also see the point behind your:

"if you use one, do not tell us" ;-)

Thinking about it from that angle also makes me wonder about Assisted-by trailers themselves. If I understand the point behind "if you use one, do not tell us" correctly, then perhaps we should simply not encourage Assisted-by: LLM trailers, since such a trailer explicitly records the very fact that we might prefer the project not to be told about.

Of course, I am simply worried that an Assisted-by trailer might create some legal risk. I am not a lawyer, though, so I do not know whether that concern is actually well-founded.

On the other hand, I can also understand why the kernel community made a different trade-off and prefers disclosure. Knowing that a tool was involved gives the maintainer additional information, and the maintainer can then decide according to their own judgment whether that information should affect how the patch is handled. (possibly there are other reasons)

That was what I was trying, rather unsuccessfully, to get at before. I am sorry that my earlier replies made it sound as though I was singling out Johannes as a problematic case.

Sorry again for the confusion and the noise.

Thanks,
Weijie

#15 lore raw
Quoted 2 lines · Weijie Yuan

What I was trying to understand is how that fits with the particular DCO concern being discussed here.

You may never be able to tell where the AI output came from, but you can see if the updated code has resemblance to fixes we applied in the past to correct similar problems, for example. After all, you yourself without help by AI can copy our code to your patch to enhance our code, and that is perfectly legit.

Take for example 5fe676f448 (t1300: remove global config settings injected by test-lib.sh, 2026-04-26) that added

      test_might_fail git config --global --unset-all safe.bareRepository

that clearly mimicked the tests that prepared the stage by clearing a relevant configuration variable done in an earier 313eec177a (safe.directory: allow "lead/ing/path/*" match, 2024-05-29).

By "sufficient due diligence", what I meant was that I trust Dscho well enough that he's done a similar analysis to make sure that he is copying from ourselves.

#16 lore raw
Quoted 3 lines · Junio C Hamano

By "sufficient due diligence", what I meant was that I trust Dscho well enough that he's done a similar analysis to make sure that he is copying from ourselves.

... or wrote things using what he learned from other places that are OK to copy from (like code of BSD licensed projects).

#17 lore raw
Quoted 20 lines
Quoted 2 lines · Weijie Yuan

What I was trying to understand is how that fits with the particular DCO concern being discussed here.

You may never be able to tell where the AI output came from, but you can see if the updated code has resemblance to fixes we applied in the past to correct similar problems, for example. After all, you yourself without help by AI can copy our code to your patch to enhance our code, and that is perfectly legit.

Take for example 5fe676f448 (t1300: remove global config settings injected 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).

Quoted 6 lines

By "sufficient due diligence", what I meant was that I trust Dscho well enough that he's done a similar analysis to make sure that he is copying from ourselves.

... or wrote things using what he learned from other places that are OK to copy from (like code of BSD licensed projects).

Ah, I see it clearly now. This could make us able to keep the provenance of the patch under control.

Thanks so much for taking the time to give me this example and explanation. And very sorry for bringing Dscho into the discussion, sorry.

Apologize for my recklessness. Thank you very much.

#18 lore raw
In reply to Junio C Hamano
Quoted 4 lines · Junio C Hamano

By "sufficient due diligence", what I meant was that I trust Dscho well enough that he's done a similar analysis to make sure that he is copying from ourselves.

i think the salient point is that it is never reasonable to make that assumption when an AI tool is used. some of the tools now reportedly detect themselves when they are outright plagiarizing (and identifying the tool in a trailer would actually give some assurance in that regard), but if the tool fails or doesn't have the feature in the first place, then all bets are off. Literally No-one (TM) will use multiple code search engines to check whether the generated code doesn't contain sufficiently large fragments that are (near-)verbatim copies from incompatibly licensed code bases.