)]}'
{
  "commit": "bd5e567dc75abae58cb364d1e55cbaf67edb8c98",
  "tree": "611dd2c0b366417ab81e9ea0cd61cb8edb470837",
  "parents": [
    "aeb582a98374c094361cba1bd756dc6307432c42"
  ],
  "author": {
    "name": "Jonathan Tan",
    "email": "jonathantanmy@google.com",
    "time": "Wed Mar 13 10:57:38 2019 -0700"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Thu Mar 14 09:36:48 2019 +0900"
  },
  "message": "submodule: explain first attempt failure clearly\n\nWhen cloning with --recurse-submodules a superproject with at least one\nsubmodule with HEAD pointing to an unborn branch, the clone goes\nsomething like this:\n\n\tCloning into \u0027test\u0027...\n\t\u003cmessages about cloning of superproject\u003e\n\tSubmodule \u0027\u003cname\u003e\u0027 (\u003curi\u003e) registered for path \u0027\u003csubmodule path\u003e\u0027\n\tCloning into \u0027\u003csubmodule path\u003e\u0027...\n\tfatal: Couldn\u0027t find remote ref HEAD\n\tUnable to fetch in submodule path \u0027\u003csubmodule path\u003e\u0027\n\t\u003cmessages about fetching with SHA-1\u003e\n\tFrom \u003curi\u003e\n\t * branch            \u003chash\u003e -\u003e FETCH_HEAD\n\tSubmodule path \u0027\u003csubmodule path\u003e\u0027: checked out \u0027\u003chash\u003e\u0027\n\nIn other words, first, a fetch is done with no hash arguments (that is,\na fetch of HEAD) resulting in a \"Couldn\u0027t find remote ref HEAD\" error;\nthen, a fetch is done given a hash, which succeeds.\n\nThe fetch given a hash was added in fb43e31f2b (\"submodule: try harder\nto fetch needed sha1 by direct fetching sha1\", 2016-02-24), and the\n\"Unable to fetch...\" message was downgraded from a fatal error to a\nnotice in e30d833671 (\"git-submodule.sh: try harder to fetch a\nsubmodule\", 2018-05-16).\n\nThis commit improves the notice to be clearer that we are retrying the\nfetch, and that the previous messages (in particular, the fatal errors\nfrom fetch) do not necessarily indicate that the whole command fails. In\nother words:\n\n - If the HEAD-fetch succeeds and we then have the commit we want,\n   git-submodule prints no explanation.\n - If the HEAD-fetch succeeds and we do not have the commit we want, but\n   the hash-fetch succeeds, git-submodule prints no explanation.\n - If the HEAD-fetch succeeds and we do not have the commit we want, but\n   the hash-fetch fails, git-submodule prints a fatal error.\n - If the HEAD-fetch fails, fetch prints a fatal error, and\n   git-submodule informs the user that it will retry by fetching\n   specific commits by hash.\n   - If the hash-fetch then succeeds, git-submodule prints no\n     explanation (besides the ones already printed).\n   - If the HEAD-fetch then fails, git-submodule prints a fatal error.\n\nIt could be said that we should just eliminate the HEAD-fetch\naltogether, but that changes some behavior (in particular, some refs\nthat were opportunistically updated would no longer be), so I have left\nthat alone for now.\n\nThere is an analogous situation with the fetching code in fetch_finish()\nand surrounding functions. For now, I have added a NEEDSWORK.\n\nSigned-off-by: Jonathan Tan \u003cjonathantanmy@google.com\u003e\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b5f2beee60ab59a04b5b236da8df39403009db1b",
      "old_mode": 33261,
      "old_path": "git-submodule.sh",
      "new_id": "cc750b57b23de89d95f863494fa8f213d7ce4950",
      "new_mode": 33261,
      "new_path": "git-submodule.sh"
    },
    {
      "type": "modify",
      "old_id": "934ecfa2943bcb5ee87e7ac431b5332a5f3adcde",
      "old_mode": 33188,
      "old_path": "submodule.c",
      "new_id": "b6f6fa72d739c068819dfa18ea97f64761f46733",
      "new_mode": 33188,
      "new_path": "submodule.c"
    }
  ]
}