)]}'
{
  "commit": "b4e4386a2e58ba6ce8d02b952f1bc6ceb8fc95d1",
  "tree": "8a6988f138507986f935085bbe06c6ef7692ae73",
  "parents": [
    "3814a9e1fe77c01c7e872c25afa198537d4ac780"
  ],
  "author": {
    "name": "Tom de Vries",
    "email": "tdevries@suse.de",
    "time": "Fri Sep 24 12:39:14 2021 +0200"
  },
  "committer": {
    "name": "Tom de Vries",
    "email": "tdevries@suse.de",
    "time": "Fri Sep 24 12:39:14 2021 +0200"
  },
  "message": "[gdb/testsuite] Add gdb.testsuite/dump-system-info.exp\n\nWhen interpreting the testsuite results, it\u0027s often relevant what kind of\nmachine the testsuite ran on.  On a local machine one can just do\n/proc/cpuinfo, but in case of running tests using a remote system\nthat distributes test runs to other remote systems that are not directly\naccessible, that\u0027s not possible.\n\nFix this by dumping /proc/cpuinfo into the gdb.log, as well as lsb_release -a\nand uname -a.\n\nWe could do this at the start of each test run, by putting it into unix.exp\nor some such.  However, this might be too verbose, so we choose to put it into\nits own test-case, such that it get triggered in a full testrun, but not when\nrunning one or a subset of tests.\n\nWe put the test-case into the gdb.testsuite directory, which is currently the\nonly place in the testsuite where we do not test gdb.   [ Though perhaps this\ncould be put into a new gdb.info directory, since the test-case doesn\u0027t\nactually test the testsuite. ]\n\nTested on x86_64-linux.\n",
  "tree_diff": [
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "bf181469bd516b2c2205ae3a2f71664a329c3ffe",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.testsuite/dump-system-info.exp"
    }
  ]
}