Invalid `toFileRange.lines` when using `--unified=0`

[pdgendt]

When trying to parse a minimal diff using git diff --unified=0 the resulting lines in toFileRange is the same as the start value.

The following example (adding a single line):

diff --git a/tests/test_commands.py b/tests/test_commands.py
index 8838bb3bb0992afe26109081704e8c67a49a171a..ed42fd1d1e649d1197772f2047d7ce2a4461a533 100644
--- a/tests/test_commands.py
+++ b/tests/test_commands.py
@@ -12,0 +13 @@ def test_parse_git_version():
+    # add this

Results in:

{
  "type": "GitDiff",
  "files": [
    {
      "type": "ChangedFile",
      "chunks": [
        {
          "context": "def test_parse_git_version():",
          "type": "Chunk",
          "toFileRange": {
            "start": 13,
            "lines": 13
          },
          "fromFileRange": {
            "start": 12,
            "lines": 0
          },
          "changes": [
            {
              "type": "AddedLine",
              "lineAfter": 13,
              "content": "    # add this"
            }
          ]
        }
      ],
      "path": "tests/test_commands.py"
    }
  ]
}

[pdgendt]

From wikipedia:

The hunk range information contains two hunk ranges. The range for the hunk of the original file is preceded by a minus symbol, and the range for the new file is preceded by a plus symbol. Each hunk range is of the format l,s where l is the starting line number and s is the number of lines the change hunk applies to for each respective file. In many versions of GNU diff, each range can omit the comma and trailing value s, in which case s defaults to 1. Note that the only really interesting value is the l line number of the first range; all the other values can be computed from the diff.

[yeonjuan]

@pdgendt Thank you for your report. I missed the notification about the issue, I'll check it out.

[yeonjuan]

@pdgendt Thanks it's fixed in 0.0.17