)]}'
{
  "commit": "04c9c5e8d2d99050d260149cad9dde1302a02ff4",
  "tree": "5d6ced1446fcd7d5271e57c1d2a26e56fce28dc3",
  "parents": [
    "bb5da75d6116c35924a04a418ef4c3182663d0a2"
  ],
  "author": {
    "name": "Patrick Steinhardt",
    "email": "ps@pks.im",
    "time": "Tue Mar 24 07:18:26 2026 +0100"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Tue Mar 24 08:39:37 2026 -0700"
  },
  "message": "commit-graph: fix writing generations with dates exceeding 34 bits\n\nThe `timestamp_t` type is declared as `uintmax_t` and thus typically has\n64 bits of precision. Usually, the full precision of such dates is not\nrequired: it would be comforting to know that Git is still around in\nmillions of years, but all in all the chance is rather low.\n\nWe abuse this fact in the commit-graph: instead of storing the full 64\nbits of precision, committer dates only store 34 bits. This is still\nplenty of headroom, as it means that we can represent dates until year\n2514. Commits which are dated beyond that year will simply get a date\nwhose remaining bits are masked.\n\nThe result of this is somewhat curious: the committer date will be\ndifferent depending on whether a commit gets parsed via the commit-graph\nor via the object database. This isn\u0027t really too much of an issue in\ngeneral though, as we don\u0027t typically use the date parsed from the\ncommit-graph in user-facing output.\n\nBut with 024b4c9697 (commit: make `repo_parse_commit_no_graph()` more\nrobust, 2026-02-16) it started to become a problem when writing the\ncommit-graph itself. This commit changed `repo_parse_commit_no_graph()`\nso that we re-parse the commit via the object database in case it was\nalready parsed beforehand via the commit-graph.\n\nThe consequence is that we may now act with two different commit dates\nat different stages:\n\n  - Initially, we use the 34-bit precision timestamp when writing the\n    chunk generation data. We thus correctly compute the offsets\n    relative to the on-disk timestamp here.\n\n  - Later, when writing the overflow data, we may end up with the\n    full-precision timestamp. When the date is larger than 34 bits the\n    result of this is an underflow when computing the offset.\n\nThis causes a mismatch in the number of generation data overflow records\nwe want to write, and that ultimately causes Git to die.\n\nIntroduce a new helper function that computes the generation offset for\na commit while correctly masking the date to 34 bits. This makes the\npreviously-implicit assumptions about the commit date precision explicit\nand thus hopefully less fragile going forward.\n\nAdapt sites that compute the offset to use the function.\n\nSigned-off-by: Patrick Steinhardt \u003cps@pks.im\u003e\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "6b1f02e1792b64745633ffb9ce20de10c1a41d3e",
      "old_mode": 33188,
      "old_path": "commit-graph.c",
      "new_id": "ad3582451d5dfa87b2f705398ea91159e99104aa",
      "new_mode": 33188,
      "new_path": "commit-graph.c"
    },
    {
      "type": "modify",
      "old_id": "98c69109632c2d7c626f23e60d70a1e48b5c9a0d",
      "old_mode": 33261,
      "old_path": "t/t5318-commit-graph.sh",
      "new_id": "1c40f904f8bb31d72785ee42953d70983c219fbb",
      "new_mode": 33261,
      "new_path": "t/t5318-commit-graph.sh"
    }
  ]
}