commit-graph: use timestamp_t for max parent generation accumulator

[newren]

We found a few repositories in the wild with commits whose authors were apparently on a computer in the year 2120 when they recorded their commits. Apparently, in a century from now, some folks are going to have a really weird timezone as well (-13068837), though the timezone doesn't factor into this patch at all.

cc: Patrick Steinhardt ps@pks.im
cc: Derrick Stolee stolee@gmail.com

[newren]

/submit

[gitgitgadget]

Submitted as pull.2148.git.1781420271100.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-2148/newren/commit-graph-fix-ccd-uint32-truncation-v1

To fetch this version to local tag pr-2148/newren/commit-graph-fix-ccd-uint32-truncation-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-2148/newren/commit-graph-fix-ccd-uint32-truncation-v1

[gitgitgadget]

Patrick Steinhardt wrote on the Git mailing list (how to reply to this email):

On Sun, Jun 14, 2026 at 06:57:50AM +0000, Elijah Newren via GitGitGadget wrote:
>     commit-graph: use timestamp_t for max parent generation accumulator
>     
>     We found a few repositories in the wild with commits whose authors were
>     apparently on a computer in the year 2120 when they recorded their
>     commits. Apparently, in a century from now, some folks are going to have
>     a really weird timezone as well (-13068837), though the timezone doesn't
>     factor into this patch at all.

I'd really be curious which other parts of Git will start to break once
we cross that threshold. Would it make sense if we maybe expanded our
linux-TEST-VARS job to create commits with a date beyond UINT32_MAX?
Something like the patch at the end of this mail. And yes, many tests
break with the patch applied. From all I've seen though many of those
failures are benign, even though I'd bet that there might even be some
"proper" failures in there.

Anyway, this is of course outside the scope of this patch series.

> diff --git a/commit-graph.c b/commit-graph.c
> index 9abe62bd5a..4b7156fd76 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -1669,7 +1669,7 @@ static void compute_reachable_generation_numbers(
>  			struct commit *current = list->item;
>  			struct commit_list *parent;
>  			int all_parents_computed = 1;
> -			uint32_t max_gen = 0;
> +			timestamp_t max_gen = 0;
>  
>  			for (parent = current->parents; parent; parent = parent->next) {
>  				repo_parse_commit(info->r, parent->item);

This looks obviously correct.

> diff --git a/t/t5328-commit-graph-64bit-time.sh b/t/t5328-commit-graph-64bit-time.sh
> index d8891e6a92..bc651b69de 100755
> --- a/t/t5328-commit-graph-64bit-time.sh
> +++ b/t/t5328-commit-graph-64bit-time.sh
> @@ -74,6 +74,15 @@ test_expect_success 'single commit with generation data exceeding UINT32_MAX' '
>  	git -C repo-uint32-max commit-graph verify
>  '
>  
> +test_expect_success 'descendant of commit with date exceeding UINT32_MAX' '
> +	git init repo-uint32-max-descendant &&
> +	test_commit -C repo-uint32-max-descendant \
> +		--date "@4294967300 +0000" future-parent &&
> +	test_commit -C repo-uint32-max-descendant present-day-child &&
> +	git -C repo-uint32-max-descendant commit-graph write --reachable &&
> +	git -C repo-uint32-max-descendant commit-graph verify
> +'

Makes sense. Thanks!

Patrick

diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 809c662124..e78902b671 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -136,12 +136,19 @@ sane_unset () {
 test_tick () {
 	if test -z "${test_tick+set}"
 	then
-		test_tick=1112911993
+		if test_bool_env GIT_TEST_FUTURE false
+		then
+			test_tick=4294697600
+			test_tick_prefix=@
+		else
+			test_tick=1112911993
+			test_tick_prefix=
+		fi
 	else
 		test_tick=$(($test_tick + 60))
 	fi
-	GIT_COMMITTER_DATE="$test_tick -0700"
-	GIT_AUTHOR_DATE="$test_tick -0700"
+	GIT_COMMITTER_DATE="$test_tick_prefix$test_tick -0700"
+	GIT_AUTHOR_DATE="$test_tick_prefix$test_tick -0700"
 	export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
 }
 
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 4a7357b547..54798fb3f1 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -558,12 +558,26 @@ TEST_AUTHOR_LOCALNAME=author
 TEST_AUTHOR_DOMAIN=example.com
 GIT_AUTHOR_EMAIL=${TEST_AUTHOR_LOCALNAME}@${TEST_AUTHOR_DOMAIN}
 GIT_AUTHOR_NAME='A U Thor'
-GIT_AUTHOR_DATE='1112354055 +0200'
 TEST_COMMITTER_LOCALNAME=committer
 TEST_COMMITTER_DOMAIN=example.com
 GIT_COMMITTER_EMAIL=${TEST_COMMITTER_LOCALNAME}@${TEST_COMMITTER_DOMAIN}
 GIT_COMMITTER_NAME='C O Mitter'
-GIT_COMMITTER_DATE='1112354055 +0200'
+
+case "${GIT_TEST_FUTURE:-false}" in
+1|on|true|yes)
+	GIT_AUTHOR_DATE="${GIT_TEST_DATE:-@4294697300 +0200}"
+	GIT_COMMITTER_DATE="${GIT_TEST_DATE:-@4294697300 +0200}"
+	;;
+0|off|false|no)
+	GIT_AUTHOR_DATE="${GIT_TEST_DATE:-1112354055 +0200}"
+	GIT_COMMITTER_DATE="${GIT_TEST_DATE:-1112354055 +0200}"
+	;;
+*)
+	echo "GIT_TEST_FUTURE requires a boolean" >&2
+	exit 1
+	;;
+esac
+
 GIT_MERGE_VERBOSITY=5
 GIT_MERGE_AUTOEDIT=no
 export GIT_MERGE_VERBOSITY GIT_MERGE_AUTOEDIT

[gitgitgadget]

User Patrick Steinhardt <ps@pks.im> has been added to the cc: list.

[gitgitgadget]

Derrick Stolee wrote on the Git mailing list (how to reply to this email):

On 6/15/26 4:11 AM, Patrick Steinhardt wrote:
> On Sun, Jun 14, 2026 at 06:57:50AM +0000, Elijah Newren via GitGitGadget wrote:
>>      commit-graph: use timestamp_t for max parent generation accumulator
>>      >>      We found a few repositories in the wild with commits whose authors were
>>      apparently on a computer in the year 2120 when they recorded their
>>      commits. Apparently, in a century from now, some folks are going to have
>>      a really weird timezone as well (-13068837), though the timezone doesn't
>>      factor into this patch at all.

>> @@ -1669,7 +1669,7 @@ static void compute_reachable_generation_numbers(
>>   			struct commit *current = list->item;
>>   			struct commit_list *parent;
>>   			int all_parents_computed = 1;
>> -			uint32_t max_gen = 0;
>> +			timestamp_t max_gen = 0;
>>   >>   			for (parent = current->parents; parent; parent = parent->next) {
>>   				repo_parse_commit(info->r, parent->item);
> > This looks obviously correct.

I agree. I was surprised this was the only necessary change, but
your message clearly describes how the timing of the patch that
delivered this change contributed to the mismatch.

Thanks,
-Stolee

[gitgitgadget]

User Derrick Stolee <stolee@gmail.com> has been added to the cc: list.

[gitgitgadget]

This patch series was integrated into seen via git@cc33e45.