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
Thanks for the bug report! Yes I do think that diffy should better handle windows line endings although I think that fixing one of those asserts is more straight forward than the other.
let p_crlf = Patch::from_str(&patch_crlf).unwrap()
Parsing a patch with CRLF line endings should succeed. Taking a quick look at this it seems like theres an easy fix for this in the patch header parsing logic.
assert!(diffy::apply(text_crlf, &p_lf).is_ok());
This one is a bit more complicated. Applying a patch which has different line endings from the text that is being patched is something that would require a bit more smarts on the matching of where the patch should be applied. Some other tools seem to either fail to apply (e.g git-apply) while others do some fuzzy-matching to get the patch to apply (e.g. unix `patch) but then leave the patched with with mixed line endings. So I'm not quite sure what the best way to tackle this would be.
Fixing the first issue, though, would let you do the following without issue (patching a crlf file with a crlf patch):
Yeah now that you mention it, it would probably be reasonable to leave the mixed line endings case alone, though I do think that leaving the patched file with mixed line endings is an acceptable outcome with that kind of edge case.
The other two should be pretty simple, though, yes. I can take a look into them.
This crate seems to fail if either the patch text or the text being patched contain Windows line endings. For example, the following test cases:
The latter two asserts fail. Would you be open to supporting Windows line endings in this crate? I'd be happy to PR if one is welcome.
The text was updated successfully, but these errors were encountered: