)]}'
{
  "commit": "2e2d5ac184de8facde4e14cec8b4e2a154480ed8",
  "tree": "7000d0063d6eacf35fab609487416284da838b05",
  "parents": [
    "e6e045f80314a4f37745676cbb92c8271ad07815"
  ],
  "author": {
    "name": "Stefan Beller",
    "email": "sbeller@google.com",
    "time": "Fri Jun 30 13:53:07 2017 -0700"
  },
  "committer": {
    "name": "Junio C Hamano",
    "email": "gitster@pobox.com",
    "time": "Fri Jun 30 13:59:42 2017 -0700"
  },
  "message": "diff.c: color moved lines differently\n\nWhen a patch consists mostly of moving blocks of code around, it can\nbe quite tedious to ensure that the blocks are moved verbatim, and not\nundesirably modified in the move. To that end, color blocks that are\nmoved within the same patch differently. For example (OM, del, add,\nand NM are different colors):\n\n    [OM]  -void sensitive_stuff(void)\n    [OM]  -{\n    [OM]  -        if (!is_authorized_user())\n    [OM]  -                die(\"unauthorized\");\n    [OM]  -        sensitive_stuff(spanning,\n    [OM]  -                        multiple,\n    [OM]  -                        lines);\n    [OM]  -}\n\n           void another_function()\n           {\n    [del] -        printf(\"foo\");\n    [add] +        printf(\"bar\");\n           }\n\n    [NM]  +void sensitive_stuff(void)\n    [NM]  +{\n    [NM]  +        if (!is_authorized_user())\n    [NM]  +                die(\"unauthorized\");\n    [NM]  +        sensitive_stuff(spanning,\n    [NM]  +                        multiple,\n    [NM]  +                        lines);\n    [NM]  +}\n\nHowever adjacent blocks may be problematic. For example, in this\npotentially malicious patch, the swapping of blocks can be spotted:\n\n    [OM]  -void sensitive_stuff(void)\n    [OM]  -{\n    [OMA] -        if (!is_authorized_user())\n    [OMA] -                die(\"unauthorized\");\n    [OM]  -        sensitive_stuff(spanning,\n    [OM]  -                        multiple,\n    [OM]  -                        lines);\n    [OMA] -}\n\n           void another_function()\n           {\n    [del] -        printf(\"foo\");\n    [add] +        printf(\"bar\");\n           }\n\n    [NM]  +void sensitive_stuff(void)\n    [NM]  +{\n    [NMA] +        sensitive_stuff(spanning,\n    [NMA] +                        multiple,\n    [NMA] +                        lines);\n    [NM]  +        if (!is_authorized_user())\n    [NM]  +                die(\"unauthorized\");\n    [NMA] +}\n\nIf the moved code is larger, it is easier to hide some permutation in the\ncode, which is why some alternative coloring is needed.\n\nThis patch implements the first mode:\n* basic alternating \u0027Zebra\u0027 mode\n  This conveys all information needed to the user.  Defer customization to\n  later patches.\n\nFirst I implemented an alternative design, which would try to fingerprint\na line by its neighbors to detect if we are in a block or at the boundary.\nThis idea iss error prone as it inspected each line and its neighboring\nlines to determine if the line was (a) moved and (b) if was deep inside\na hunk by having matching neighboring lines. This is unreliable as the\nwe can construct hunks which have equal neighbors that just exceed the\nnumber of lines inspected. (Think of \u0027AXYZBXYZCXYZD..\u0027 with each letter\nas a line, that is permutated to AXYZCXYZBXYZD..\u0027).\n\nInstead this provides a dynamic programming greedy algorithm that finds\nthe largest moved hunk and then has several modes on highlighting bounds.\n\nA note on the options \u0027--submodule\u003ddiff\u0027 and \u0027--color-words/--word-diff\u0027:\nIn the conversion to use emit_line in the prior patches both submodules\nas well as word diff output carefully chose to call emit_line with sign\u003d0.\nAll output with sign\u003d0 is ignored for move detection purposes in this\npatch, such that no weird looking output will be generated for these\ncases. This leads to another thought: We could pass on \u0027--color-moved\u0027 to\nsubmodules such that they color up moved lines for themselves. If we\u0027d do\nso only line moves within a repository boundary are marked up.\n\nIt is useful to have moved lines colored, but there are annoying corner\ncases, such as a single line moved, that is very common. For example\nin a typical patch of C code, we have closing braces that end statement\nblocks or functions.\n\nWhile it is technically true that these lines are moved as they show up\nelsewhere, it is harmful for the review as the reviewers attention is\ndrawn to such a minor side annoyance.\n\nFor now let\u0027s have a simple solution of hardcoding the number of\nmoved lines to be at least 3 before coloring them. Note, that the\nlength is applied across all blocks to find the \u0027lonely\u0027 blocks\nthat pollute new code, but do not interfere with a permutated\nblock where each permutation has less lines than 3.\n\nHelped-by: Jonathan Tan \u003cjonathantanmy@google.com\u003e\nSigned-off-by: Stefan Beller \u003csbeller@google.com\u003e\nSigned-off-by: Junio C Hamano \u003cgitster@pobox.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "31720abf8f9cc6ce8e62de9a67afb54d8e20a7a8",
      "old_mode": 33188,
      "old_path": "diff.c",
      "new_id": "084ecc5678cc0e01d34d75544124dfc4152cc0ed",
      "new_mode": 33188,
      "new_path": "diff.c"
    },
    {
      "type": "modify",
      "old_id": "4a3b9bde4064ba365dcf836092f7aef0e749896c",
      "old_mode": 33188,
      "old_path": "diff.h",
      "new_id": "3196802673694dbc656a8c7b61f21d48baeeb32f",
      "new_mode": 33188,
      "new_path": "diff.h"
    },
    {
      "type": "modify",
      "old_id": "289806d0c7eb02e0acc5244df5e3999d45b4e085",
      "old_mode": 33261,
      "old_path": "t/t4015-diff-whitespace.sh",
      "new_id": "29704ae14e27b9f4053464cf9e78ff7cb243f087",
      "new_mode": 33261,
      "new_path": "t/t4015-diff-whitespace.sh"
    }
  ]
}