)]}'
{
  "log": [
    {
      "commit": "94f582f82a85a941678c80c60a3baa8187c74217",
      "tree": "83653a3a93b9291d658025a800d5fbed00ee484c",
      "parents": [
        "a36a151e79be1562d6fea3ec4698f23e7102a26f"
      ],
      "author": {
        "name": "Robert P. J. Day",
        "email": "rpjday@mindspring.com",
        "time": "Tue Oct 16 23:26:11 2007 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@woody.linux-foundation.org",
        "time": "Wed Oct 17 08:42:47 2007 -0700"
      },
      "message": "Force erroneous inclusions of compiler-*.h files to be errors\n\nReplace worthless comments with actual preprocessor errors when including\nthe wrong versions of the compiler.h files.\n\n[akpm@linux-foundation.org: make it work]\nSigned-off-by: Robert P. J. Day \u003crpjday@mindspring.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "c5e631cf65f4d6875efcd571275436f2964a8b48",
      "tree": "1aee9d61560ee369b4a2f077a79e37ab868a4b2d",
      "parents": [
        "f34d9d2dcb7f17b64124841345b23adc0843e7a5"
      ],
      "author": {
        "name": "Rusty Russell",
        "email": "rusty@rustcorp.com.au",
        "time": "Sun May 06 14:51:05 2007 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@woody.linux-foundation.org",
        "time": "Mon May 07 12:13:00 2007 -0700"
      },
      "message": "ARRAY_SIZE: check for type\n\nWe can use a gcc extension to ensure that ARRAY_SIZE() is handed an array,\nnot a pointer.  This is especially important when code is changed from a\nfixed array to a pointer.  I assume the Intel compiler doesn\u0027t support\n__builtin_types_compatible_p.\n\n[jdike@addtoit.com: uml: update UML definition of ARRAY_SIZE]\nSigned-off-by: Rusty Russell \u003crusty@rustcorp.com.au\u003e\nSigned-off-by: Jeff Dike \u003cjdike@linux.intel.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "9490991482a2091a828d997adbc088e24c310a4d",
      "tree": "dcdd9febee63e82cd792250a8a4c4dd8e6aab4be",
      "parents": [
        "a8127717cb24be7b8827a8d9e0ddbfde6b392146"
      ],
      "author": {
        "name": "Borislav Petkov",
        "email": "bbpetkov@yahoo.de",
        "time": "Sun May 06 14:49:17 2007 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@woody.linux-foundation.org",
        "time": "Mon May 07 12:12:52 2007 -0700"
      },
      "message": "Add unitialized_var() macro for suppressing gcc warnings\n\nIntroduce a macro for suppressing gcc from generating a warning about a\nprobable uninitialized state of a variable.\n\nExample:\n\n-\tspinlock_t *ptl;\n+\tspinlock_t *uninitialized_var(ptl);\n\nNot a happy solution, but those warnings are obnoxious.\n\n- Using the usual pointlessly-set-it-to-zero approach wastes several\n  bytes of text.\n\n- Using a macro means we can (hopefully) do something else if gcc changes\n  cause the `x \u003d x\u0027 hack to stop working\n\n- Using a macro means that people who are worried about hiding true bugs\n  can easily turn it off.\n\nSigned-off-by: Borislav Petkov \u003cbbpetkov@yahoo.de\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
      "tree": "0bba044c4ce775e45a88a51686b5d9f90697ea9d",
      "parents": [],
      "author": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "message": "Linux-2.6.12-rc2\n\nInitial git repository build. I\u0027m not bothering with the full history,\neven though we have it. We can create a separate \"historical\" git\narchive of that later if we want to, and in the meantime it\u0027s about\n3.2GB when imported into git - space that would just make the early\ngit days unnecessarily complicated, when we don\u0027t have a lot of good\ninfrastructure for it.\n\nLet it rip!\n"
    }
  ]
}