)]}'
{
  "commit": "11de748d66a0b358b01c2ca1a03b6455b33f808b",
  "tree": "bf70cc0aeb5e64337619e9c0b3434bc424a9edfd",
  "parents": [
    "d88c8d5d4b7c458b3c0f894ad46700aa4fca7b39"
  ],
  "author": {
    "name": "Xùdōng Yáng",
    "email": "wyverald@gmail.com",
    "time": "Fri Nov 05 01:56:32 2021 +1100"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Thu Nov 04 07:56:32 2021 -0700"
  },
  "message": "Use repo-relative labels wherever possible (#9187)\n\n* Use repo-relative labels wherever possible\r\n\r\nThe label `@com_google_protobuf//:foo` within the protobuf repo is often synonymous with just `//:foo`. We should prefer the latter as it allows us to use a shorter name for the module in the Bazel Central Registry (so just \"protobuf\" instead of \"com_google_protobuf\").\r\n\r\nNote that the semantics can be subtle: in a macro, plain strings are anchored to the *calling* repo, so if we just use `//:foo` as the default value of a macro argument, it will be resolved to `@myrepo//:foo` if the macro is called from the repo `@myrepo`. In this case, it\u0027s necessary to directly call the `Label()` constructor to anchor the string label to the repo where the .bzl file lives.\r\n\r\nSee https://github.com/bazelbuild/bazel-central-registry/pull/28#issuecomment-954741081 for a bit more context.\r\n\r\n* fix protobuf_deps.bzl",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "9716128121573afe74b5e25b77e7748e20c97600",
      "old_mode": 33188,
      "old_path": "protobuf.bzl",
      "new_id": "26b6625327900efc9888270cd1fd00e517c9c17c",
      "new_mode": 33188,
      "new_path": "protobuf.bzl"
    },
    {
      "type": "modify",
      "old_id": "32f38ebb6ea0b759362f9dd4bbb9c442834766fc",
      "old_mode": 33188,
      "old_path": "protobuf_deps.bzl",
      "new_id": "45e413d94bc66437d79a281ffa1fbbe7f581fc4b",
      "new_mode": 33188,
      "new_path": "protobuf_deps.bzl"
    }
  ]
}