Discrepancy between Gitlab diff API and go-gitdiff parsed output.

[chakravarthysm]

Hi,

I'm using go-gitdiff to parse git diff patch files in Gitlab and derive some metrics, I used to do same by using diff response of Gitlab diff API.

I see there is some discrepancy between the results.
If I move & rename certain file with with minimal changes, go-gitdiff patch parsed output shows the file in old path as deleted -

(*gitdiff.File)(0xc00013e480)({
 OldName: (string) (len=59) "adapters/phasedAdapters/executeAdapters/execute_adapters.go",
 NewName: (string) "",
 IsNew: (bool) false,
 IsDelete: (bool) true,
 IsCopy: (bool) false,
 IsRename: (bool) false,
 OldMode: (os.FileMode) -rw-r--r--,
 NewMode: (os.FileMode) ----------,
 OldOIDPrefix: (string) (len=7) "f08cca6",
 NewOIDPrefix: (string) (len=7) "0000000",
 Score: (int) 0

and shows the file at new path as new file -

(*gitdiff.File)(0xc00013e2d0)({
 OldName: (string) "",
 NewName: (string) (len=33) "adapters/phase/execute/execute.go",
 IsNew: (bool) true,
 IsDelete: (bool) false,
 IsCopy: (bool) false,
 IsRename: (bool) false,
 OldMode: (os.FileMode) ----------,
 NewMode: (os.FileMode) -rw-r--r--,
 OldOIDPrefix: (string) (len=7) "0000000",
 NewOIDPrefix: (string) (len=7) "a1d4924",
 Score: (int) 0

whereas in Gitlab MR diff view I get move and rename as -
adapters/phasedAdapters/executeAdapters/execute_adapters.go → adapters/phase/execute/execute.go

In Gitlab diff API, the response for the file I get it as -

 {
        "old_path": "adapters/phasedAdapters/executeAdapters/execute_adapters.go",
        "new_path": "adapters/phase/execute/execute.go",
        "a_mode": "100644",
        "b_mode": "100644",
        "new_file": false,
        "renamed_file": true,
        "deleted_file": false
}

Gitlab determines the file was just renamed and move to different path whereas go-gitdiff assumes it as a new file and considers file at old path as deleted, is this expected?

[bluekeyes]

I think this is expected. go-gitdiff tries to parse the literal input patches without much interpretation, so my suspicion is that if you look at the input patch file, you will also see an addition and deletion instead of a rename. If the patch is written as a rename instead, go-gitdiff should parse it that way, but it will not combine two existing files.

This matches how Git itself behaves. Renames are recorded as additions and deletions, but the commands that produce diffs use heuristics based on file similarity to detect renames and copies. If you have these heuristics enabled, the output will be a single file with different old and new paths and some additional headers indicating that a rename (or copy) took place. Without those heuristics, you'll get two individual files.

It looks like the Gitlab API is aware of these heuristics, but the API or tool that generates the patch file is not. I think that leaves you with a few options:

1. Change the source tool to generate rename patches instead of additions and deletions
2. Write your own heuristic logic to evaluate the parsed diffs and detect renames based on file similarity
3. Extend the parsed output with Gitlab's diff API output to set the rename status

At the moment, I don't plan to implement any kind of rename heuristic like (2) in this library, as it moves the library closer to diff computation and I'd prefer to keep it focused on parsing and applying patches.

[chakravarthysm]

Yeah you are right, thanks for the detailed explanation, I now understand how this works, I would like to keep the parsed output and the derived metrics based from that to match how Git behaves by default instead of Gitlab diff output based on heuristics.