Hunks at the start or end of a file may have less context on that side.
The locator previously ignored this and could apply them elsewhere with
--fuzz=0.
Keep them at the start or end until enough fuzz is allowed.
I think this also explains/fixes the behavior I was previously confused
about when a hunk from the beginning of a file is found later. The
missing leading context marks the beginning of the original file, so
moving the hunk requires fuzz even when the remaining context matches.
The same applies to missing trailing context at the end of a file.
Rejected hunk ranges are adjusted by line-count changes from earlier
hunks before they are written. The failure diagnostic added the same
adjustment again, reporting a line one too large after an insertion.
Use the already-adjusted hunk range when reporting a failure.
GNU comparison was controlled per test executable. That kept process
tests in test_unit from being compared, while enabling comparison there
would also run its unit tests twice.
Introduce COMPAT_TEST for cases that run against both sb_patch and GNU
patch. Keep PATCH_TEST for project-specific behavior and TEST for unit
coverage. Mark stable GNU differences as expected compatibility failures.
Keep host-dependent ed behavior project-only because GNU delegates those
scripts to an external editor.
Merge the normal and conditional PTY tests into one patch_tests runner
now that executable boundaries no longer control GNU comparison. Keep
test_oom separate because it runs patch_oom.
There were some problems using fstreams on mingw due to wide strings.
The MSVC compiler as a non standard extension allows fstream to take a
fstream. But the mingw toolchain does not have the same functionality.
Create a File class wrapper around C FILE* to fix this problem.
Found by attempting to apply a patch which contained a git submodule
update. This requires the heuristic for determining which file to patch
to change as otherwise for such a patch we would otherwise consider it
impossible to determine the filepath for the git submodule which is
being patched.
If this scenario occurs, write to the reject file and proceed to the
next patch.
This requires a refactor of the applier as previously it was the only
place which would apply reject files. Now the driving patch loop may
also write to reject files.
There is some ugly duplication being added here that should be tidied up
in the future. Until the structure of apply patch is better defined,
leave the FIXME for now.
Shannon Booth