You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Add stubs of three new tests
* Flesh out one test
* Add more stubs
* First draft of new applyPatch; seems to be fucked currently
* Fix some bugs in my work
* Fix more bugs
* Fix another bug
* Fix another bug
* Fix a bad test
* Fix another bug
* Fix a test bug
* Make distance-iterator behaviour match its documentation
* More tests
* New test
* rearrange planned tests a bit
* Add a test
* Add failing test - a bug, I think?
* Fix bug and fix test
* Add another test case
* Add more tests
* Delete redundant test
* Add another test
* Add another test
* Placate eslint
* Add a silly additional test to placate istanbul
* Fix something silly I did, and further improve coverage metric in doing so
* Add more tests to pump up coverage metric further
* Eliminate for...of loops to placate the coverage checker
* Add yet more tests to reach 100% coverage
* Add docs
* Tweak docs
* Tweak docs
* Add release notes
Copy file name to clipboardExpand all lines: README.md
+10-2Lines changed: 10 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -119,13 +119,21 @@ Broadly, jsdiff's diff functions all take an old text and a new text and perform
119
119
120
120
*`Diff.applyPatch(source, patch[, options])`- attempts to apply a unified diff patch.
121
121
122
-
If the patch was applied successfully, returns a string containing the patched text. If the patch could not be applied (because some hunks in the patch couldn't be fitted to the text in `source`), returns false.
122
+
Hunks are applied first to last. `applyPatch` first tries to apply the first hunk at the line number specified in the hunk header, and with all context lines matching exactly. If that fails, it tries scanning backwards and forwards, one line at a time, to find a place to apply the hunk where the context lines match exactly. If that still fails, and `fuzzFactor` is greater than zero, it increments the maximum number ofmismatches (missing, extra, or changed context lines) that there can be between the hunk context and a region where we are trying to apply the patch such that the hunk will still be considered to match. Regardlessof`fuzzFactor`, lines to be deleted in the hunk *must* be present for a hunk to match, and the context lines *immediately* before and after an insertion must match exactly.
123
+
124
+
Once a hunk is successfully fitted, the process begins again with the next hunk. Regardlessof`fuzzFactor`, later hunks must be applied later in the file than earlier hunks.
125
+
126
+
If a hunk cannot be successfully fitted *anywhere*with fewer than `fuzzFactor` mismatches, `applyPatch` fails and returns `false`.
127
+
128
+
If a hunk is successfully fitted but not at the line number specified by the hunk header, all subsequent hunks have their target line number adjusted accordingly. (e.g. if the first hunk is applied 10 lines below where the hunk header said it should fit, `applyPatch` will *start* looking for somewhere to apply the second hunk 10 lines below where its hunk header says it goes.)
129
+
130
+
If the patch was applied successfully, returns a string containing the patched text. If the patch could not be applied (because some hunks in the patch couldn't be fitted to the text in `source`), `applyPatch` returns false.
123
131
124
132
`patch` may be a string diff or the output from the `parsePatch` or `structuredPatch` methods.
125
133
126
134
The optional `options` object may have the following keys:
127
135
128
-
- `fuzzFactor`: Number of lines that are allowed to differ before rejecting a patch. Defaults to 0.
136
+
- `fuzzFactor`: Maximum Levenshtein distance (in lines deleted, added, or subtituted) between the context shown in a patch hunk and the lines found in the file. Defaults to 0.
129
137
- `autoConvertLineEndings`: If `true`, and if the file to be patched consistently uses different line endings to the patch (i.e. either the file always uses Unix line endings while the patch uses Windows ones, or vice versa), then `applyPatch` will behave as if the line endings in the patch were the same as those in the source file. (If `false`, the patch will usually fail to apply in such circumstances since lines deleted in the patch won't be considered to match those in the source file.) Defaults to `true`.
130
138
-`compareLine(lineNumber, line, operation, patchContent)`: Callback used to compare to given lines to determine if they should be considered equal when patching. Defaults to strict equality but may be overridden to provide fuzzier comparison. Shouldreturnfalseif the lines should be rejected.
Copy file name to clipboardExpand all lines: release-notes.md
+4Lines changed: 4 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -28,6 +28,10 @@
28
28
-[#521](https://github.com/kpdecker/jsdiff/pull/521)**the `callback` option is now supported by `structuredPatch`, `createPatch
29
29
-[#529](https://github.com/kpdecker/jsdiff/pull/529)**`parsePatch` can now parse patches where lines starting with `--` or `++` are deleted/inserted**; previously, there were edge cases where the parser would choke on valid patches or give wrong results.
30
30
-[#530](https://github.com/kpdecker/jsdiff/pull/530)**Added `ignoreNewlineAtEof` option` to `diffLines`**
31
+
-[#533](https://github.com/kpdecker/jsdiff/pull/533)**`applyPatch` uses an entirely new algorithm for fuzzy matching.** Differences between the old and new algorithm are as follows:
32
+
* The `fuzzFactor` now indicates the maximum [*Levenshtein* distance](https://en.wikipedia.org/wiki/Levenshtein_distance) that there can be between the context shown in a hunk and the actual file content at a location where we try to apply the hunk. (Previously, it represented a maximum [*Hamming* distance](https://en.wikipedia.org/wiki/Hamming_distance), meaning that a single insertion or deletion in the source file could stop a hunk from applying even with a high `fuzzFactor`.)
33
+
* A hunk containing a deletion can now only be applied in a context where the line to be deleted actually appears verbatim. (Previously, as long as enough context lines in the hunk matched, `applyPatch` would apply the hunk anyway and delete a completely different line.)
34
+
* The context line immediately before and immediately after an insertion must match exactly between the hunk and the file for a hunk to apply. (Previously this was not required.)
0 commit comments