)]}'
{
  "commit": "a65990c737f184fa0b0c9ccbd3eb24a1ec90ee4c",
  "tree": "c5030bdc3c533cdbd82aa407efd9325e804fe5cd",
  "parents": [
    "c5656ab3a3fe3bd1bcfc843acdca6b1f985eb85c"
  ],
  "author": {
    "name": "Matthias Sohn",
    "email": "matthias.sohn@sap.com",
    "time": "Tue Sep 01 10:52:07 2026 +0200"
  },
  "committer": {
    "name": "Matthias Sohn",
    "email": "matthias.sohn@sap.com",
    "time": "Wed Sep 02 00:27:40 2026 +0200"
  },
  "message": "InterruptTimer: fix spurious interrupt when begin() reuses same timeout\n\nWhen begin() was called with the same timeout as the previous call,\nthe notify to the AlarmThread was skipped as an optimisation. This was\nunsafe when the AlarmThread was in its idle wait (after end()): if that\nidle wait was started long before begin() was called, it could expire\nat or after the new deadline, causing the AlarmThread to see delay \u003c\u003d 0\nand fire a spurious interrupt.\n\nFix by tracking idleWakeAt — the absolute time at which the current\nidle wait will expire. begin() now sends notifyAll() when the thread is\nidle and its wait would expire at or after the new deadline, ensuring\nthe AlarmThread re-arms itself correctly. The optimisation is preserved\nfor the common case where the thread is actively timing (idleWakeAt\u003d\u003d0).\n\nThis manifested as a flaky\nInterruptTimerTest.testRepeatedShortThanTooLong()\nin CI job running on Linux where coarser timer resolution and higher\nscheduling jitter made the race window large enough to hit reliably.\n\nChange-Id: I5d5635a66f9fa5b9f68791017e09d5d3d08135dd\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e7174127dfb9cc28996763ac11daa35d2a710ca4",
      "old_mode": 33188,
      "old_path": "org.eclipse.jgit/src/org/eclipse/jgit/util/io/InterruptTimer.java",
      "new_id": "a076e4ed1430ff721e208e8fa59acfdd0ff04cce",
      "new_mode": 33188,
      "new_path": "org.eclipse.jgit/src/org/eclipse/jgit/util/io/InterruptTimer.java"
    }
  ]
}