)]}'
{
  "log": [
    {
      "commit": "af558e33bedab672f5cfd3260bce7445e353fe21",
      "tree": "eb89187b6c12640a00584bd35be035ba332e4af3",
      "parents": [
        "d5b337b4877f7c4e1d761434ee04d045b0201e03"
      ],
      "author": {
        "name": "J. Bruce Fields",
        "email": "bfields@citi.umich.edu",
        "time": "Thu Sep 06 12:34:25 2007 -0400"
      },
      "committer": {
        "name": "J. Bruce Fields",
        "email": "bfields@citi.umich.edu",
        "time": "Fri Oct 03 16:19:02 2008 -0400"
      },
      "message": "nfsd: common grace period control\n\nRewrite grace period code to unify management of grace period across\nlockd and nfsd.  The current code has lockd and nfsd cooperate to\ncompute a grace period which is satisfactory to them both, and then\nindividually enforce it.  This creates a slight race condition, since\nthe enforcement is not coordinated.  It\u0027s also more complicated than\nnecessary.\n\nHere instead we have lockd and nfsd each inform common code when they\nenter the grace period, and when they\u0027re ready to leave the grace\nperiod, and allow normal locking only after both of them are ready to\nleave.\n\nWe also expect the locks_start_grace()/locks_end_grace() interface here\nto be simpler to build on for future cluster/high-availability work,\nwhich may require (for example) putting individual filesystems into\ngrace, or enforcing grace periods across multiple cluster nodes.\n\nSigned-off-by: J. Bruce Fields \u003cbfields@citi.umich.edu\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"
    }
  ]
}