)]}'
{
  "commit": "8ad8a0e61d919e76f521f3124c91bd46fbaa84e2",
  "tree": "fba74635a3cab4aecd5f9d7dd8672756db3e67e8",
  "parents": [
    "d1f70d9929ddd2748ccc9c1dd2f9603068e1f3e6"
  ],
  "author": {
    "name": "Shawn O. Pearce",
    "email": "sop@google.com",
    "time": "Fri May 29 18:28:25 2009 -0700"
  },
  "committer": {
    "name": "Shawn O. Pearce",
    "email": "sop@google.com",
    "time": "Fri May 29 18:45:17 2009 -0700"
  },
  "message": "Change DWIMery hack for dealing with rewound remote branch\n\nThe trick of looking at the reflog for the remote tracking branch\nand only going back one commit works some of the time, but not all of\nthe time.  Its sort of relying on the fact that the user didn\u0027t use\n`repo sync -n` or `git fetch` to only update the tracking branches\nand skip the working directory update.\n\nDoing this right requires looking through the history of the SHA-1\nsource (what the upstream used to be) and finding a spot where the\nDAG diveraged away suddenly, and consider that to be the rewind\npoint.  That\u0027s really difficult to do, as we don\u0027t have a clear\npicture of what that old point was.\n\nA close approximation is to list all of the commits that are in\nHEAD, but not the new upstream, and rebase all of those where the\ncommitter email address is this user\u0027s email address.  In most cases,\nthis will effectively rebase only the user\u0027s new original work.\n\nIf the user is the project maintainer and rewound the branch\nthemselves, and they don\u0027t want all of the commits they have created\nto be rebased onto the new upstream, they should handle the rebase\non their own, after the sync is complete.\n\nSigned-off-by: Shawn O. Pearce \u003csop@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "53fd38ee0b5e526c0e833b565d34ca6560bae955",
      "old_mode": 33188,
      "old_path": "project.py",
      "new_id": "cab47152b66abe45cf98b66aae5033d353235fbe",
      "new_mode": 33188,
      "new_path": "project.py"
    }
  ]
}