)]}'
{
  "log": [
    {
      "commit": "b4955ce3dd0818b56da532a16c9a4a3804a558ee",
      "tree": "6e01667181bfc495b56e39748783ad2235a4f56e",
      "parents": [
        "c475a8ab625d567eacf5e30ec35d6d8704558062"
      ],
      "author": {
        "name": "Abhijit Karmarkar",
        "email": "abhijitk@veritas.com",
        "time": "Tue Jun 21 17:15:13 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Tue Jun 21 18:46:21 2005 -0700"
      },
      "message": "[PATCH] msync: check pte dirty earlier\n\nIt\u0027s common practice to msync a large address range regularly, in which\noften only a few ptes have actually been dirtied since the previous pass.\n\nsync_pte_range then goes much faster if it tests whether pte is dirty\nbefore locating and accessing each struct page cacheline; and it is hardly\nslowed by ptep_clear_flush_dirty repeating that test in the opposite case,\nwhen every pte actually is dirty.\n\nBut beware, s390\u0027s pte_dirty always says false, since its dirty bit is kept\nin the storage key, located via the struct page address.  So skip this\noptimization in its case: use a pte_maybe_dirty macro which just says true\nif page_test_and_clear_dirty is implemented.\n\nSigned-off-by: Abhijit Karmarkar \u003cabhijitk@veritas.com\u003e\nSigned-off-by: Hugh Dickins \u003chugh@veritas.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"
    }
  ]
}