Skip to content

"{lineno} | {linecontent}" compensation broken... #37

@jeske

Description

@jeske

A common "quasi form" of diff is when there are line numbers before line content, as in:

-2122 | linecontent

However, when a diff starts with insert lines, there is no way to know if the diff needs some kind of compensation.. aka, if it inserts

+2122 | linecontent

There is no way to know if it wants to insert "linecontent" or "2122 | linecontent" from insert lines alone, this must be determined by using a context or delete line that matches.

gitdiff does this correctly.. however, it does not properly persist this compensation as applying to the entire diff, as a result, when an insert line comes along, there is no compensation, and it buggers the diff apply..

Example:

-2 | line 2
3 | line 3
+4 | line 4

File content:

line 1
line 2
line 3

Resulting file after gitdiff butchers it:

line 1
line 3
4 | line 4

IMO, git diff should get out of the business of doing line compensation for "### | linecontent" style input.. but if it is going to do it, it's WAY more complicated than what gitdiff is doing.... It should be:

  1. if the first-diff-line is delete/context in the file sets the "line adaptation" for the file, if anything else doens' match the diff is failed
  2. if the first diff line is insert, we assume it's a verbatim insertion
  3. if a later delete/context line is encountered that conflicts with Bump mixin-deep from 1.3.1 to 1.3.2 #2, then the diff must be restarted at the start with this new compensation method as the only acceptable compensation

Restarting can be complicated, depending on how you handle it.. so an alternative is a two pass algorithm, but this will cause the user to wait for the ENTIRE diff to be validated before any line can be applied, whjich is kind of junk in some scenerios..

This is why IMO gitdiff parser should either (a) get entirely out of the business of handling any messed up line input formats, or (b) it should have a pluggable compensation method, that the external caller can get more involved with handling the detection/restart issues with.

The reason I am not submitting patches, is that gitdiff parser was unsuitable for me in other ways as well, so I implemented my own (more complicated) streaming parser with a streaming listerner interface... perhaps if I have time I will submit patches to fix this gitdiff parser, but probably not as I'm not using it anymore.

enjoy.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions