)]}'
{
  "log": [
    {
      "commit": "fb5eeeee44edb248b4837416966f19731f497f79",
      "tree": "f947a4dcf103f55d526bb5c71f69b657d8f22e61",
      "parents": [
        "28a42b9ea7e42e1efb02cc2dcacba0b6af234e1b"
      ],
      "author": {
        "name": "Paul Jackson",
        "email": "pj@sgi.com",
        "time": "Sun Oct 30 15:02:33 2005 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Sun Oct 30 17:37:21 2005 -0800"
      },
      "message": "[PATCH] cpusets: bitmap and mask remap operators\n\nIn the forthcoming task migration support, a key calculation will be\nmapping cpu and node numbers from the old set to the new set while\npreserving cpuset-relative offset.\n\nFor example, if a task and its pages on nodes 8-11 are being migrated to\nnodes 24-27, then pages on node 9 (the 2nd node in the old set) should be\nmoved to node 25 (the 2nd node in the new set.)\n\nAs with other bitmap operations, the proper way to code this is to provide\nthe underlying calculation in lib/bitmap.c, and then to provide the usual\ncpumask and nodemask wrappers.\n\nThis patch provides that.  These operations are termed \u0027remap\u0027 operations.\nBoth remapping a single bit and a set of bits is supported.\n\nSigned-off-by: Paul Jackson \u003cpj@sgi.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"
    }
  ]
}