{"push_id":2744280545,"size":21,"distinct_size":0,"ref":"refs/heads/jch","head":"1ac17a46fabb55e69e4e2eb1427b5a995009c04a","before":"c1b8b44962c2284f4124869f0f1329d5c46915c4","commits":[{"sha":"bbb19a8b06f58f6335e287f90bbde42098219ff3","author":{"name":"Brandon Williams","email":"508c49d25413636f1741a48f4d767eeebd424c11@google.com"},"message":"fetch-pack: mark die strings for translation\n\nSigned-off-by: Brandon Williams <bmwill@google.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/bbb19a8b06f58f6335e287f90bbde42098219ff3"},{"sha":"15cfc985e0e0ec6976637d66dd341743cc958373","author":{"name":"Jonathan Tan","email":"a1f160b521cd973a24f632d654869fc52afb36fa@google.com"},"message":"t5702: test fetch with multiple refspecs at a time\n\nExtend the protocol v2 tests to also test fetches with multiple refspecs\nspecified. This also covers the previously uncovered cases of fetching\nwith prefix matching and fetching by SHA-1.\n\nSigned-off-by: Jonathan Tan <jonathantanmy@google.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/15cfc985e0e0ec6976637d66dd341743cc958373"},{"sha":"2b554353a5f0463dec44b827e2d1423b698d06d3","author":{"name":"Jonathan Tan","email":"a1f160b521cd973a24f632d654869fc52afb36fa@google.com"},"message":"fetch: send \"refs/tags/\" prefix upon CLI refspecs\n\nWhen performing tag following, in addition to using the server's\n\"include-tag\" capability to send tag objects (and emulating it if the\nserver does not support that capability), \"git fetch\" relies upon the\npresence of refs/tags/* entries in the initial ref advertisement to\nlocally create refs pointing to the aforementioned tag objects. When\nusing protocol v2, refs/tags/* entries in the initial ref advertisement\nmay be suppressed by a ref-prefix argument, leading to the tag object\nbeing downloaded, but the ref not being created.\n\nCommit dcc73cf7ff (\"fetch: generate ref-prefixes when using a configured\nrefspec\", 2018-05-18) ensured that \"refs/tags/\" is always sent as a ref\nprefix when \"git fetch\" is invoked with no refspecs, but not when \"git\nfetch\" is invoked with refspecs. Extend that functionality to make it\nwork in both situations.\n\nThis also necessitates a change another test which tested ref\nadvertisement filtering using tag refs - since tag refs are sent by\ndefault now, the test has been switched to using branch refs instead.\n\nSigned-off-by: Jonathan Tan <jonathantanmy@google.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/2b554353a5f0463dec44b827e2d1423b698d06d3"},{"sha":"b20a3cbb887be494a93d54858052f0a4f8df17c1","author":{"name":"Junio C Hamano","email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com"},"message":"Merge branch 'sb/blame-color' into jk/banned-function\n\n* sb/blame-color:\n  blame: prefer xsnprintf to strcpy for colors","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/b20a3cbb887be494a93d54858052f0a4f8df17c1"},{"sha":"bb21640f23b74dbde1d319689a85f61b3e291b4c","author":{"name":"Jeff King","email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net"},"message":"automatically ban strcpy()\n\nThere are a few standard C functions (like strcpy) which are\neasy to misuse. E.g.:\n\n  char path[PATH_MAX];\n  strcpy(path, arg);\n\nmay overflow the \"path\" buffer. Sometimes there's an earlier\nconstraint on the size of \"arg\", but even in such a case\nit's hard to verify that the code is correct. If the size\nreally is unbounded, you're better off using a dynamic\nhelper like strbuf:\n\n  struct strbuf path = STRBUF_INIT;\n  strbuf_addstr(path, arg);\n\nor if it really is bounded, then use xsnprintf to show your\nexpectation (and get a run-time assertion):\n\n  char path[PATH_MAX];\n  xsnprintf(path, sizeof(path), \"%s\", arg);\n\nwhich makes further auditing easier.\n\nWe'd usually catch undesirable code like this in a review,\nbut there's no automated enforcement. Adding that\nenforcement can help us be more consistent and save effort\n(and a round-trip) during review.\n\nThis patch teaches the compiler to report an error when it\nsees strcpy (and will become a model for banning a few other\nfunctions). This has a few advantages over a separate\nlinting tool:\n\n  1. We know it's run as part of a build cycle, so it's\n     hard to ignore. Whereas an external linter is an extra\n     step the developer needs to remember to do.\n\n  2. Likewise, it's basically free since the compiler is\n     parsing the code anyway.\n\n  3. We know it's robust against false positives (unlike a\n     grep-based linter).\n\nThe two big disadvantages are:\n\n  1. We'll only check code that is actually compiled, so it\n     may miss code that isn't triggered on your particular\n     system. But since presumably people don't add new code\n     without compiling it (and if they do, the banned\n     function list is the least of their worries), we really\n     only care about failing to clean up old code when\n     adding new functions to the list. And that's easy\n     enough to address with a manual audit when adding a new\n     function.\n\n  2. If this ends up generating false positives, it's going\n     to be harder to disable (as opposed to a separate\n     linter, which may have mechanisms for overriding a\n     particular case).\n\n     But the intent is to only ban functions which are\n     obviously bad, and for which we accept using an\n     alternative even when this particular use isn't buggy\n     (e.g., the xsnprintf alternative above).\n\nThe implementation here is simple: we'll define a macro for\nthe banned function which replaces it with a descriptively\nnamed but undefined function.  Replacing it with any invalid\ncode would work (since we just want to break compilation).\nBut ideally we'd meet these goals:\n\n - it should be portable; ideally this would trigger\n   everywhere, and does not need to be part of a DEVELOPER=1\n   setup (because unlike warnings which may depend on the\n   compiler or system, this is a clear indicator of\n   something wrong in the code).\n\n - it should generate a readable error that gives the\n   developer a clue what happened\n\n - it should avoid generating too much other cruft that\n   makes it hard to see the actual error\n\n - it should mention the original callsite in the error\n\nThe output with this patch looks like this (using gcc 7, on\na checkout without 022d2ac1f3, which removes the final\nstrcpy from blame.c):\n\n      CC builtin/blame.o\n  In file included from ./git-compat-util.h:1242:0,\n                   from ./cache.h:4,\n                   from builtin/blame.c:8:\n  builtin/blame.c: In function ‘cmd_blame’:\n  ./banned.h:11:22: error: implicit declaration of function ‘sorry_strcpy_is_a_banned_function’ [-Werror=implicit-function-declaration]\n   #define BANNED(func) sorry_##func##_is_a_banned_function()\n                        ^\n  ./banned.h:13:21: note: in expansion of macro ‘BANNED’\n   #define strcpy(x,y) BANNED(strcpy)\n                       ^~~~~~\n  builtin/blame.c:1074:4: note: in expansion of macro ‘strcpy’\n      strcpy(repeated_meta_color, GIT_COLOR_CYAN);\n      ^~~~~~\n\nThis pretty clearly shows the original callsite along with\nthe descriptive function name, and it mentions banned.h,\nwhich contains more information.\n\nWhat's not perfectly ideal is:\n\n  1. We'll only trigger with -Wimplicit-function-declaration\n     (and only stop compilation with -Werror). These are\n     generally enabled by DEVELOPER=1. If you _don't_ have\n     that set, we'll still catch the problem, but only at\n     link-time, with a slightly less useful message:\n\n       /usr/bin/ld: builtin/blame.o: in function `cmd_blame':\n       /home/peff/tmp/builtin/blame.c:1074: undefined reference to `sorry_strcpy_is_a_banned_function'\n       collect2: error: ld returned 1 exit status\n\n     If instead we convert this to a reference to an\n     undefined variable, that always dies immediately. But\n     gcc seems to print the set of errors twice, which\n     clutters things up.\n\n  2. The expansion through BANNED() adds an extra layer of\n     error. Curiously, though, removing it (and just\n     expanding strcpy directly to the bogus function name)\n     causes gcc _not_ to report the original line of code.\n\nSo experimentally, this seems to behave pretty well on gcc.\nClang looks OK, too, though:\n\n - it actually produces a better message for the undeclared\n   identifier than for the implicit function (it doesn't\n   double the errors, and for the implicit function it\n   actually produces an extra complaint about\n   strict-prototypes).\n\n - the BANNED indirection has no effect (it shows the\n   original line of code either way)\n\nSo if we want to optimize for clang's output, we could\nswitch both of those decisions.\n\nNote that the linux kernel has a similar mechanism which\ngoes by BUILD_BUG_ON_MSG(). It works by declaring a one-off\nfunction with gcc's error attribute. That doesn't work for\nus here, because we'd like to work even on non-gcc\ncompilers (and in my opinion the compiler output is actually\n_less_ readable).\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/bb21640f23b74dbde1d319689a85f61b3e291b4c"},{"sha":"77f798f62eaa2c4c04925683698c2a000a0e72b7","author":{"name":"Jeff King","email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net"},"message":"banned.h: mark strcat() as banned\n\nThe strcat() function has all of the same overflow problems\nas strcpy(). And as a bonus, it's easy to end up\naccidentally quadratic, as each subsequent call has to walk\nthrough the existing string.\n\nThe last strcat() call went away in f063d38b80 (daemon: use\ncld->env_array when re-spawning, 2015-09-24). In general,\nstrcat() can be replaced either with a dynamic string\n(strbuf or xstrfmt), or with xsnprintf if you know the\nlength is bounded.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/77f798f62eaa2c4c04925683698c2a000a0e72b7"},{"sha":"7f3b6ad4f4133fea3a7551439b30cf74c9681f05","author":{"name":"Jeff King","email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net"},"message":"banned.h: mark sprintf() as banned\n\nThe sprintf() function (and its variadic form vsprintf) make\nit easy to accidentally introduce a buffer overflow. If\nyou're thinking of using them, you're better off either\nusing a dynamic string (strbuf or xstrfmt), or xsnprintf if\nyou really know that you won't overflow. The last sprintf()\ncall went away quite a while ago in f0766bf94e (fsck: use\nfor_each_loose_file_in_objdir, 2015-09-24).\n\nNote that we respect HAVE_VARIADIC_MACROS here, which some\nancient platforms lack. As a fallback, we can just \"guess\"\nthat the caller will provide 3 arguments. If they do, then\nthe macro will work as usual. If not, then they'll get a\nslightly less useful error, like:\n\n  git.c:718:24: error: macro \"sprintf\" passed 3 arguments, but takes just 2\n\nThat's not ideal, but it at least alerts them to the problem\narea. And anyway, we're primarily targeting people adding\nnew code. Most developers should be on modern enough\nplatforms to see the normal \"good\" error message.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/7f3b6ad4f4133fea3a7551439b30cf74c9681f05"},{"sha":"aed86049e87b14766b58045edc589f0a37c69bc8","author":{"name":"Jeff King","email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net"},"message":"banned.h: mark strncpy() as banned\n\nThe strncpy() function is less horrible than strcpy(), but\nis still pretty easy to misuse because of its funny\ntermination semantics. Namely, that if it truncates it omits\nthe NUL terminator, and you must remember to add it\nyourself. Even if you use it correctly, it's sometimes hard\nfor a reader to verify this without hunting through the\ncode. If you're thinking about using it, consider instead:\n\n  - strlcpy() if you really just need a truncated but\n    NUL-terminated string (we provide a compat version, so\n    it's always available)\n\n  - xsnprintf() if you're sure that what you're copying\n    should fit\n\n  - strbuf or xstrfmt() if you need to handle\n    arbitrary-length heap-allocated strings\n\nNote that there is one instance of strncpy in\ncompat/regex/regcomp.c, which is fine (it allocates a\nsufficiently large string before copying). But this doesn't\ntrigger the ban-list even when compiling with NO_REGEX=1,\nbecause:\n\n  1. we don't use git-compat-util.h when compiling it\n     (instead we rely on the system includes from the\n     upstream library); and\n\n  2. It's in an \"#ifdef DEBUG\" block\n\nSince it's doesn't trigger the banned.h code, we're better\noff leaving it to keep our divergence from upstream minimal.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/aed86049e87b14766b58045edc589f0a37c69bc8"},{"sha":"77aa03d6c7f07db4a5d34afe8f5b3a55e801057c","author":{"name":"Jeff King","email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net"},"message":"reencode_string: use st_add/st_mult helpers\n\nWhen converting a string with iconv, if the output buffer\nisn't big enough, we grow it. But our growth is done without\nany concern for integer overflow. So when we add:\n\n  outalloc = sofar + insz * 2 + 32;\n\nwe may end up wrapping outalloc (which is a size_t), and\nallocating a too-small buffer. We then manipulate it\nfurther:\n\n  outsz = outalloc - sofar - 1;\n\nand feed outsz back to iconv. If outalloc is wrapped and\nsmaller than sofar, we'll end up with a small allocation but\nfeed a very large outsz to iconv, which could result in it\noverflowing the buffer.\n\nCan we use this to construct an attack wherein the victim\nclones a repository with a very large commit object with an\nencoding header, and running \"git log\" reencodes it into\nutf8, causing an overflow?\n\nAn attack of this sort is likely impossible in practice.\n\"sofar\" is how many output bytes we've written total, and\n\"insz\" is the number of input bytes remaining. Imagine our\ninput doubles in size as we output it (which is easy to do\nby converting latin1 to utf8, for example), and that we\nstart with N input bytes. Our initial output buffer also\nstarts at N bytes, so after the first call we'd have N/2\ninput bytes remaining (insz), and have written N bytes\n(sofar). That means our next allocation will be\n(N + N/2 * 2 + 32) bytes, or (2N + 32).\n\nWe can therefore overflow a 32-bit size_t with a commit\nmessage that's just under 2^31 bytes, assuming it consists\nmostly of \"doubling\" sequences (e.g., latin1 0xe1 which\nbecomes utf8 0xc3 0xa1).\n\nBut we'll never make it that far with such a message. We'll\nbe spending 2^31 bytes on the original string. And our\ninitial output buffer will also be 2^31 bytes. Which is not\ngoing to succeed on a system with a 32-bit size_t, since\nthere will be other things using the address space, too. The\ninitial malloc will fail.\n\nIf we imagine instead that we can triple the size when\nconverting, then our second allocation becomes\n(N + 2/3N * 2 + 32), or (7/3N + 32). That still requires two\nallocations of 3/7 of our address space (6/7 of the total)\nto succeed.\n\nIf we imagine we can quadruple, it becomes (5/2N + 32); we\nneed to be able to allocate 4/5 of the address space to\nsucceed.\n\nThis might start to get plausible. But is it possible to get\na 4-to-1 increase in size? Probably if you're converting to\nsome obscure encoding. But since git defaults to utf8 for\nits output, that's the likely destination encoding for an\nattack. And while there are 4-character utf8 sequences, it's\nunlikely that you'd be able find a single-byte source\nsequence in any encoding.\n\nSo this is certainly buggy code which should be fixed, but\nit is probably not a useful attack vector.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/77aa03d6c7f07db4a5d34afe8f5b3a55e801057c"},{"sha":"c7d017d7e1cca37ca20f73c11fa9f1b319a2c3a5","author":{"name":"Jeff King","email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net"},"message":"reencode_string: use size_t for string lengths\n\nThe iconv interface takes a size_t, which is the appropriate\ntype for an in-memory buffer. But our reencode_string_*\nfunctions use integers, meaning we may get confusing results\nwhen the sizes exceed INT_MAX. Let's use size_t\nconsistently.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/c7d017d7e1cca37ca20f73c11fa9f1b319a2c3a5"},{"sha":"26114c00be2cd49b97b18df69a909d3330886e9d","author":{"name":"Jeff King","email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net"},"message":"strbuf: use size_t for length in intermediate variables\n\nA few strbuf functions store the length of a strbuf in a\ntemporary variable. We should always use size_t for this, as\nit's possible for a strbuf to exceed an \"int\" (e.g., a 2GB\nstring on a 64-bit system). This is unlikely in practice,\nbut we should try to behave sensibly on silly or malicious\ninput.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/26114c00be2cd49b97b18df69a909d3330886e9d"},{"sha":"f3e76ed228d60688b49dbc2735e4633e55969e30","author":{"name":"Jeff King","email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net"},"message":"strbuf_readlink: use ssize_t\n\nThe return type of readlink() is ssize_t, not int. This\nprobably doesn't matter in practice, as it would require a\n2GB symlink destination, but it doesn't hurt to be careful.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/f3e76ed228d60688b49dbc2735e4633e55969e30"},{"sha":"765b496dc6963ad8aaf40e9ac5dee358aa7fea47","author":{"name":"Jeff King","email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net"},"message":"pass st.st_size as hint for strbuf_readlink()\n\nWhen we initially added the strbuf_readlink() function in\nb11b7e13f4 (Add generic 'strbuf_readlink()' helper function,\n2008-12-17), the point was that we generally have a _guess_\nas to the correct size based on the stat information, but we\ncan't necessarily trust it.\n\nOver the years, a few callers have grown up that simply pass\nin 0, even though they have the stat information. Let's have\nthem pass in their hint for consistency (and in theory\nefficiency, since it may avoid an extra resize/syscall loop,\nbut neither location is probably performance critical).\n\nNote that st.st_size is actually an off_t, so in theory we\nneed xsize_t() here. But none of the other callsites use it,\nand since this is just a hint, it doesn't matter either way\n(if we wrap we'll simply start with a too-small hint and\nthen eventually complain when we cannot allocate the\nmemory).\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/765b496dc6963ad8aaf40e9ac5dee358aa7fea47"},{"sha":"7726d360b5ba859ae2b6ceefc5d88cc518c78063","author":{"name":"Jeff King","email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net"},"message":"strbuf_humanise: use unsigned variables\n\nAll of the numeric formatting done by this function uses\n\"%u\", but we pass in a signed \"int\". The actual range\ndoesn't matter here, since the conditional makes sure we're\nalways showing reasonably small numbers. And even gcc's\nformat-checker does not seem to mind. But it's potentially\nconfusing to a reader of the code to see the mismatch.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/7726d360b5ba859ae2b6ceefc5d88cc518c78063"},{"sha":"d08b7351fbe9c2611d886287c67e8223a36174a9","author":{"name":"Junio C Hamano","email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com"},"message":"Merge branch 'jk/banned-function' into jch\n\n* jk/banned-function:\n  banned.h: mark strncpy() as banned\n  banned.h: mark sprintf() as banned\n  banned.h: mark strcat() as banned\n  automatically ban strcpy()","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/d08b7351fbe9c2611d886287c67e8223a36174a9"},{"sha":"0449191d6c166eefaa2c729b25e7578d057c92d0","author":{"name":"Junio C Hamano","email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com"},"message":"Merge branch 'bw/clone-ref-prefixes' into jch\n\n* bw/clone-ref-prefixes:\n  clone: send ref-prefixes when using protocol v2","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/0449191d6c166eefaa2c729b25e7578d057c92d0"},{"sha":"19f2a8fffaec6b9de0d88448a79de0d7f673e334","author":{"name":"Junio C Hamano","email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com"},"message":"Merge branch 'jt/tag-following-with-proto-v2-fix' into jch\n\n* jt/tag-following-with-proto-v2-fix:\n  fetch: send \"refs/tags/\" prefix upon CLI refspecs\n  t5702: test fetch with multiple refspecs at a time","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/19f2a8fffaec6b9de0d88448a79de0d7f673e334"},{"sha":"2c932585308c23330e8c35c29096b85878979e24","author":{"name":"Junio C Hamano","email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com"},"message":"Merge branch 'bw/fetch-pack-i18n' into jch\n\n* bw/fetch-pack-i18n:\n  fetch-pack: mark die strings for translation","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/2c932585308c23330e8c35c29096b85878979e24"},{"sha":"dce8f4ed3be174011d59f89fa3fef3cf411fbe9e","author":{"name":"Junio C Hamano","email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com"},"message":"Merge branch 'jk/size-t' into jch\n\n* jk/size-t:\n  strbuf_humanise: use unsigned variables\n  pass st.st_size as hint for strbuf_readlink()\n  strbuf_readlink: use ssize_t\n  strbuf: use size_t for length in intermediate variables\n  reencode_string: use size_t for string lengths\n  reencode_string: use st_add/st_mult helpers","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/dce8f4ed3be174011d59f89fa3fef3cf411fbe9e"},{"sha":"f351b0aba4335ad71f8608b268f2a1d97e1ec008","author":{"name":"Brandon Williams","email":"508c49d25413636f1741a48f4d767eeebd424c11@google.com"},"message":"pack-protocol: mention and point to docs for protocol v2\n\nSigned-off-by: Brandon Williams <bmwill@google.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/gitster/git/commits/f351b0aba4335ad71f8608b268f2a1d97e1ec008"}]}
{"actor":{"display_login":"gitster"}}