)]}'
{
  "log": [
    {
      "commit": "1e92a550e80fef01ebcc0bcd0896109cdb986c72",
      "tree": "6cdb7bc6c6ad51644f9b899b2604d26fe7cd540b",
      "parents": [
        "ddf5f75a16b3e7460ffee881795aa168dffcd0cf"
      ],
      "author": {
        "name": "Anton Blanchard",
        "email": "anton@samba.org",
        "time": "Thu Jun 15 14:11:22 2006 +1000"
      },
      "committer": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Wed Jun 21 15:01:33 2006 +1000"
      },
      "message": "[POWERPC] Fix mdelay badness on shared processor partitions\n\nOn partitioned PPC64 systems where a partition is given 1/10 of a\nprocessor, we have seen mdelay() delaying for 10 times longer than it\nshould.  The reason is that the generic mdelay(n) does n delays of 1\nmillisecond each.  However, with 1/10 of a processor, we only get a\none-millisecond timeslice every 10ms.  Thus each 1 millisecond delay\nloop ends up taking 10ms elapsed time.\n\nThe solution is just to use the PPC64 udelay function, which uses the\ntimebase to ensure that the delay is based on elapsed time rather than\nhow much processing time the partition has been given.  (Yes, the\ngeneric mdelay uses the PPC64 udelay, but the problem is that the\nstart time gets reset every millisecond, and each time it gets reset\nwe lose another 9ms.)\n\nSigned-off-by: Anton Blanchard \u003canton@samba.org\u003e\nSigned-off-by: Paul Mackerras \u003cpaulus@samba.org\u003e\nAcked-by: Andrew Morton \u003cakpm@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"
    }
  ]
}