)]}'
{
  "log": [
    {
      "commit": "4bb0d3ec3e5b1e9e2399cdc641b3b6521ac9cdaa",
      "tree": "5e8d7646f5c6a2cec990b6d591f230d496b20664",
      "parents": [
        "2a0694d15d55d0deed928786a6393d5e45e37d76"
      ],
      "author": {
        "name": "Zachary Amsden",
        "email": "zach@vmware.com",
        "time": "Sat Sep 03 15:56:36 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@evo.osdl.org",
        "time": "Mon Sep 05 00:06:11 2005 -0700"
      },
      "message": "[PATCH] i386: inline asm cleanup\n\ni386 Inline asm cleanup.  Use cr/dr accessor functions.\n\nAlso, a potential bugfix.  Also, some CR accessors really should be volatile.\nReads from CR0 (numeric state may change in an exception handler), writes to\nCR4 (flipping CR4.TSD) and reads from CR2 (page fault) prevent instruction\nre-ordering.  I did not add memory clobber to CR3 / CR4 / CR0 updates, as it\nwas not there to begin with, and in no case should kernel memory be clobbered,\nexcept when doing a TLB flush, which already has memory clobber.\n\nI noticed that page invalidation does not have a memory clobber.  I can\u0027t find\na bug as a result, but there is definitely a potential for a bug here:\n\n#define __flush_tlb_single(addr) \\\n\t__asm__ __volatile__(\"invlpg %0\": :\"m\" (*(char *) addr))\n\nSigned-off-by: Zachary Amsden \u003czach@vmware.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.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"
    }
  ]
}