Re: [PATCH] commit-graph: fix writing generations with dates exceeding 34 bits

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> this fixes a regression recently introduced by myself in 024b4c9697
> (commit: make `repo_parse_commit_no_graph()` more robust, 2026-02-16).
> The regression was found by GitLab's tests suite, see [1].

Curious.  GitLab's test suite runs pretending that it is way past
year 2600 or something?  

> [1]: https://gitlab.com/gitlab-org/gitlab/-/jobs/13522328632
> ---
>  commit-graph.c          | 31 ++++++++++++++++++++++++++++---
>  t/t5318-commit-graph.sh | 20 ++++++++++++++++++++
>  2 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/commit-graph.c b/commit-graph.c
> index f8e24145a5..7e293a1775 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -1319,6 +1319,31 @@ static int write_graph_chunk_data(struct hashfile *f,
>  	return 0;
>  }
>  
> +/*
> + * Compute the generation offset between the commit date and its generation.
> + * This is what's ultimately stored as generation number in the commit graph.
> ...
> + * actually end up storing on disk, and hence we have to mask all the other
> + * bits.
> + */
> +static timestamp_t compute_generation_offset(struct commit *c)
> +{
> +	timestamp_t masked_date = c->date & (((timestamp_t) 1 << 34) - 1);
> +	return commit_graph_data_at(c)->generation - masked_date;
> +}
> +
>  static int write_graph_chunk_generation_data(struct hashfile *f,
>  					     void *data)
>  {

The code and explanation are both in line with why we want to do
this change in the proposed log message.

> +test_expect_success TIME_IS_64BIT,TIME_T_IS_64BIT 'overflow chunk when replacing commit-graph' '
> +	test_when_finished "rm -rf repo" &&
> +	git init repo &&
> +	(
> +		cd repo &&
> +		cat >commit <<-EOF &&
> +		tree $(test_oid empty_tree)
> +		author Example <committer@example.com> 9223372036854775 +0000
> +		committer Example <committer@example.com> 9223372036854775 +0000

This timestamp is way longer than 34-bit for sure.

100000110001001001101110100101111000110101001111110111 (base 2)

> +
> +		Weird commit date
> +		EOF
> +		commit_id=$(git hash-object -t commit -w commit) &&
> +		git reset --hard "$commit_id" &&
> +		git commit-graph write --reachable &&
> +		git commit-graph write --reachable --split=replace &&
> +		git log
> +	)
> +'
> +
>  # the verify tests below expect the commit-graph to contain
>  # exactly the commits reachable from the commits/8 branch.
>  # If the file changes the set of commits in the list, then the

Will queue.  Thanks.