)]}'
{
  "commit": "5c9f9bf313e872934c9b4563b7b0bcdedb39eb86",
  "tree": "ed73e41998a70017db06e266670b5968da8bd54d",
  "parents": [
    "765428699a5381f113d19974720bc91b5bfeaf1d"
  ],
  "author": {
    "name": "Jeff King",
    "email": "peff@peff.net",
    "time": "Fri Jun 03 03:07:34 2016 -0400"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Fri Jun 03 09:00:59 2016 -0700"
  },
  "message": "rev-list: \"adjust\" results of \"--count --use-bitmap-index -n\"\n\nIf you ask rev-list for:\n\n    git rev-list --count --use-bitmap-index HEAD\n\nwe optimize out the actual traversal and just give you the\nnumber of bits set in the commit bitmap. This is faster,\nwhich is good.\n\nBut if you ask to limit the size of the traversal, like:\n\n    git rev-list --count --use-bitmap-index -n 100 HEAD\n\nwe\u0027ll still output the full bitmapped number we found. On\nthe surface, that might even seem OK. You explicitly asked\nto use the bitmap index, and it was cheap to compute the\nreal answer, so we gave it to you.\n\nBut there\u0027s something much more complicated going on under\nthe hood. If we don\u0027t have a bitmap directly for HEAD, then\nwe have to actually traverse backwards, looking for a\nbitmapped commit. And _that_ traversal is bounded by our\n`-n` count.\n\nThis is a good thing, because it bounds the work we have to\ndo, which is probably what the user wanted by asking for\n`-n`. But now it makes the output quite confusing. You might\nget many values:\n\n  - your `-n` value, if we walked back and never found a\n    bitmap (or fewer if there weren\u0027t that many commits)\n\n  - the actual full count, if we found a bitmap root for\n    every path of our traversal with in the `-n` limit\n\n  - any number in between! We might have walked back and\n    found _some_ bitmaps, but then cut off the traversal\n    early with some commits not accounted for in the result.\n\nSo you cannot even see a value higher than your `-n` and say\n\"OK, bitmaps kicked in, this must be the real full count\".\nThe only sane thing is for git to just clamp the value to a\nmaximum of the `-n` value, which means we should output the\nexact same results whether bitmaps are in use or not.\n\nThe test in t5310 demonstrates this by using `-n 1`.\nWithout this patch we fail in the full-bitmap case (where we\ndo not have to traverse at all) but _not_ in the\npartial-bitmap case (where we have to walk down to find an\nactual bitmap). With this patch, both cases just work.\n\nI didn\u0027t implement the crazy in-between case, just because\nit\u0027s complicated to set up, and is really a subset of the\nfull-count case, which we do cover.\n\nSigned-off-by: Jeff King \u003cpeff@peff.net\u003e\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "7ae255862aaa43fb20969b75d9e434902ec2cba1",
      "old_mode": 33188,
      "old_path": "builtin/rev-list.c",
      "new_id": "a96356461763621683f4c4202ccd95f30ac21fcd",
      "new_mode": 33188,
      "new_path": "builtin/rev-list.c"
    },
    {
      "type": "modify",
      "old_id": "d446706e94fb878b471e6deaebba4ec7abc76930",
      "old_mode": 33261,
      "old_path": "t/t5310-pack-bitmaps.sh",
      "new_id": "3893afd687986ec7ec9102658c8dc332c61d25fa",
      "new_mode": 33261,
      "new_path": "t/t5310-pack-bitmaps.sh"
    }
  ]
}