)]}'
{
  "commit": "132a5f96d08b616ae9cda636eced1b7317a751e9",
  "tree": "4c6eb50431c958087feec15d95ab870708b0efed",
  "parents": [
    "735539779287334ae1dcb585f5b90e902c6bf9fe"
  ],
  "author": {
    "name": "Googler",
    "email": "noreply@google.com",
    "time": "Wed Mar 08 12:25:43 2023 -0800"
  },
  "committer": {
    "name": "Copybara-Service",
    "email": "copybara-worker@google.com",
    "time": "Wed Mar 08 12:27:21 2023 -0800"
  },
  "message": "Have getFdoBuildStamp return \"SAFDO\" when a .afdo profile is supplied along with xbinary_fdo.\n\nThis change enables the fdo_type build stamp to be set to SAFDO in order to distinguish and track the prevalence of SAFDO in the fleet. As an alternative to this implementation, I also considered defining an SAFDO build feature and using a new file extention to identify SAFDO file. This CL is here unknown commit. I decided this implementation is preferable since from a blaze perspective, SAFDO is really no different that AFDO and adding a SAFDO build feature resulted in a huge amount of duplicate boilerplate code. The method used in this CL has the downside of relying on an implementation detail of SAFDO (SAFDO is afdo with xbinary_fdo set) but I think it is overall better due to to how much smaller a change it is but I am open to feedback.\n\nSee[]\n\nPiperOrigin-RevId: 515109461\nChange-Id: Idc515b058eaf0659556eb381a44fe3618e8eb435\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0051a5646b48a9025a1a026d28e3ddca93d66a50",
      "old_mode": 33188,
      "old_path": "src/main/java/com/google/devtools/build/lib/rules/cpp/CppHelper.java",
      "new_id": "3699acb5fd7d39f664922659ded76114da86b7cc",
      "new_mode": 33188,
      "new_path": "src/main/java/com/google/devtools/build/lib/rules/cpp/CppHelper.java"
    }
  ]
}