)]}'
{
  "commit": "5b1c20741838b8359193b97895cb0ff35b4ecf79",
  "tree": "cb19d353d974a3206fd5ae5e24b62d8889f3be99",
  "parents": [
    "b4ca610c3810a9881fec3e32879afea98482e3be"
  ],
  "author": {
    "name": "Mikita Belahlazau",
    "email": "nbeloglazov@google.com",
    "time": "Fri Aug 28 13:36:28 2026 -0700"
  },
  "committer": {
    "name": "Copybara-Service",
    "email": "copybara-worker@google.com",
    "time": "Fri Aug 28 13:39:58 2026 -0700"
  },
  "message": "Use negative UninterpretedOption field tags for interpreted option locations.\n\nThis allows us to extend improved SourceCodeInfo support to dot-notation options without breaking backwards compatibility. Dot-notation options like `(my_opt).a \u003d 123` already emit SourceCodeInfo location in a form of `[..., 10101, 1]` where 1 is the tag of field `a`. That location spans the whole option. But these pre-existing locations are limited as they don\u0027t provide granular information about each part of the option (e.g. location of `a`) and don\u0027t provide location for value too.\n\nUsing negative values allows us to create non-overlapping set of locations. For example in the example above we will emit (in future CL):\n\n[..., 10101] - location of the whole `(my_opt).a \u003d 123` option\n[..., 10101, 1] - legacy duplicate location of the whole `(my_opt).a \u003d 123` option\n[..., 10101, -2] - location of `(my_opt)` part\n[..., 10101, -8, 1, -2] - location of `a` part\n[..., 10101, -8, 1, -4] - location of `123` part\n\nPiperOrigin-RevId: 972764591\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "9fb5b02cd4780cd33f3c23cc788d47c0ae046dea",
      "old_mode": 33188,
      "old_path": "src/google/protobuf/option_interpreter.cc",
      "new_id": "e2cf59f645d72753ae617eae3fd1ba28bce7ad1b",
      "new_mode": 33188,
      "new_path": "src/google/protobuf/option_interpreter.cc"
    }
  ]
}