)]}'
{
  "commit": "679bac4bf3622412c29e8bca506bc670224d2e31",
  "tree": "08e61b881facf5795d24b173bf8a2adf69d5db55",
  "parents": [
    "185307d1dd1e63a8cf139c55f26895a6b378d43b"
  ],
  "author": {
    "name": "Kevin Degi",
    "email": "kdegi@codeaurora.org",
    "time": "Mon Jun 22 15:31:26 2015 -0600"
  },
  "committer": {
    "name": "Kevin Degi",
    "email": "kdegi@codeaurora.org",
    "time": "Wed Jul 15 15:53:14 2015 +0000"
  },
  "message": "project.RemoteFetch: Handle depth cases more robustly\n\nThe fetch logic for the case where depth is set and revision is a\nSHA1 has several failure modes that are not handled well by the\ncurrent logic.\n\n1) \u0027git fetch \u003cSHA1\u003e\u0027 requires git version \u003e\u003d 1.8.3\n2) \u0027git fetch \u003cSHA1\u003e\u0027 can be prevented by a configuration option on the server.\n3) \u0027git fetch --depth\u003d\u003cN\u003e \u003crefspec\u003e\u0027 can fail to contain a SHA1 specified by\n   the manifest.\n\nEach of these cases cause infinite recursion when _RemoteFetch() tries to call\nitself with current_branch_only\u003dFalse because current_branch_only is set to\nTrue when depth !\u003d None.\n\nTo try to prevent the infinite recursion, we set self.clone_depth to None\nbefore the first retry of _RemoteFetch(). This will allow the Fetch to\neventually succeed in the case where clone-depth is specified in the manifest.\nA user specified depth from the init command will still recurse infinitely.\n\nIn addition, never try to fetch a SHA1 directly if the git version being used\nis not at least 1.8.3.\n\nChange-Id: I802fc17878c0929cfd63fff611633c1d3b54ecd3\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "3f1e3b6575d38594f9d7ba2418a066337d0f0d69",
      "old_mode": 33188,
      "old_path": "project.py",
      "new_id": "2f70e996da483fbaa251001d3981909dbd164a3c",
      "new_mode": 33188,
      "new_path": "project.py"
    }
  ]
}