)]}'
{
  "commit": "4fa3f00abb55c3334cce71e201a5ff2c70f8561f",
  "tree": "8cb45d844590a141325bf1822f2e5a285a24dc70",
  "parents": [
    "d1185aa6fab2c12016e92ac9b9e448984cdc6c5d"
  ],
  "author": {
    "name": "Jonathan Tan",
    "email": "jonathantanmy@google.com",
    "time": "Mon Apr 27 17:01:09 2020 -0700"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Tue Apr 28 09:55:02 2020 -0700"
  },
  "message": "fetch-pack: in protocol v2, in_vain only after ACK\n\nWhen fetching, Git stops negotiation when it has sent at least\nMAX_IN_VAIN (which is 256) \"have\" lines without having any of them\nACK-ed. But this is supposed to trigger only after the first ACK, as\npack-protocol.txt says:\n\n  However, the 256 limit *only* turns on in the canonical client\n  implementation if we have received at least one \"ACK %s continue\"\n  during a prior round.  This helps to ensure that at least one common\n  ancestor is found before we give up entirely.\n\nThe code path for protocol v0 observes this, but not protocol v2,\nresulting in shorter negotiation rounds but significantly larger\npackfiles. Teach the code path for protocol v2 to check this criterion\nonly after at least one ACK was received.\n\nSigned-off-by: Jonathan Tan \u003cjonathantanmy@google.com\u003e\nReviewed-by: Jonathan Nieder \u003cjrnieder@gmail.com\u003e\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "66cd258c384532a14282069989d42edddb863c8f",
      "old_mode": 33188,
      "old_path": "fetch-pack.c",
      "new_id": "3891f8bb86bc6975f2060fc2fda4c9cf771915e0",
      "new_mode": 33188,
      "new_path": "fetch-pack.c"
    },
    {
      "type": "modify",
      "old_id": "6b97923964ef990a8112e753d138af386275eccb",
      "old_mode": 33261,
      "old_path": "t/t5500-fetch-pack.sh",
      "new_id": "95ed08db1b8a71044082fa5e99c96989be6c457f",
      "new_mode": 33261,
      "new_path": "t/t5500-fetch-pack.sh"
    }
  ]
}