)]}'
{
  "commit": "2454970930851179fb6486e6faa6342f008e7d9d",
  "tree": "0d8be5450225b026a077fc2c6a6a91238704ee0a",
  "parents": [
    "6531f31ef3bead57a3255fa08efa6e7553c5a9a7"
  ],
  "author": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Fri Oct 11 14:49:39 2024 -0700"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Fri Oct 11 14:50:21 2024 -0700"
  },
  "message": "BreakingChanges: early adopter option\n\nDiscussing the desire to make breaking changes, declaring that\nbreaking changes are made at a certain version boundary, and\nrecording these decisions in this document, are necessary but not\nsufficient.  We need to make sure that we can implement, test, and\ndeploy such impactful changes.\n\nEarlier we considered to guard the breaking changes with a run-time\ncheck of the `feature.git\u003cversion\u003e` configuration to allow brave\nusers and developers to opt into them as early adoptors.  But the\nengineering cost to support such a run-time switch, covering new and\ndisappearing git subcommands and how \"git help\" would adjust the\ndocumentation to the run-time switch, would be unrealistically high\nto be worth it.\n\nFormalize the mechanism based on a compile-time switch to allow\nearly adopters to opt into the breaking change in a version of Git\nbefore the planned version for the breaking change.\n\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "2b64665694f6a92058ab80027d4c4bcef401b005",
      "old_mode": 33188,
      "old_path": "Documentation/BreakingChanges.txt",
      "new_id": "eeb26c915550b2a939b668dcc2f48b427cffd1b7",
      "new_mode": 33188,
      "new_path": "Documentation/BreakingChanges.txt"
    }
  ]
}