)]}'
{
  "commit": "eb85a5f8b50dd40b02a414e9cb978c9f3d139b44",
  "tree": "ec7538b096d135e3da6ef3d5d17e6a89fa192bc6",
  "parents": [
    "b4e6c902183b65b9f9d826278fc71c890d9f52e7"
  ],
  "author": {
    "name": "Luca Milanesio",
    "email": "luca.milanesio@gmail.com",
    "time": "Mon Aug 11 11:59:45 2025 +0100"
  },
  "committer": {
    "name": "Luca Milanesio",
    "email": "luca.milanesio@gmail.com",
    "time": "Mon Aug 11 13:19:44 2025 +0100"
  },
  "message": "Sort ref-names before locking them in filterAndLock\n\nIt is a common practise to avoid locking a set of resources in an\nunpredictable order, because it would be subject to deadlocks.\n\nExample of a possible deadlock is when two replication tasks are trying\nto fetch two refs but in different order, e.g. refs/heads/branch1 and\nrefs/heads/branch2.\n\nBy locking the two refs in the same ordering, make sure that you never\nhave a situation whilst one task locks refs/heads/branch1 and the other\ntask locks refs/heads/branch2 and they both are stuck in trying each\nother branches, when the task one tries to lock refs/heads/branch2 (lock\nheld by task two) and the task two tries to lock refs/heads/branch1\n(lock held by task one).\n\nBug: Issue 437805590\nChange-Id: I7fdb072e30e2313415c58e8c8dd39dd1a1f9f6e4\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ca79bcd14d845b3ce8e40976453b945de35612fc",
      "old_mode": 33188,
      "old_path": "src/main/java/com/googlesource/gerrit/plugins/multisite/validation/MultisiteReplicationFetchFilter.java",
      "new_id": "8a4503a35ae8718afe936f5af6418af519d7f73e",
      "new_mode": 33188,
      "new_path": "src/main/java/com/googlesource/gerrit/plugins/multisite/validation/MultisiteReplicationFetchFilter.java"
    }
  ]
}