search

vaimo / composer-patches

Applies a patch from a local or remote file to any package that is part of a given composer project. Patches can be defined both on project and on package level. Optional support for patch versioning, sequencing, custom patch applier configuration and composer command for testing/troubleshooting patches.
MIT License
291 stars 41 forks source link

different line endings #46

Open puggan opened 5 years ago

puggan commented 5 years ago

If the file uses CRLF, and the patch don't uses CRLF

patching file <file>
Hunk #1 FAILED at <line> (different line endings).

If the file uses CRLF, and the patch uses CRLF, and the --binary flag is not set:

(Stripping trailing CRs from patch; use --binary to disable.)
patching file <file>
Hunk #1 FAILED at <line> (different line endings).

--ignore-whitespace dosn't work, but adding --binary worked

puggan commented 4 years ago

Converting the file to CRLF, made macos patch stop working, using CRLF in the content, but not in the header of the patch-file, made macos patch accept the patch.

peterjaap commented 4 years ago

Still running into this from time to time, when a package maintainer uses Windows...

angelomaragna commented 3 years ago

Doesn't sound like a problem pertinent to composer-patches really.

Linux uses unix filesystem. OSX uses unix filesystem. Docker images (baseline of every pipeline) are on unix filesystem. Kubernetes, runs essentially docker images. Web servers, are mostly entirely linux based.

Yet still, from time to time, you find someone opening an entirely linux based project on Windows machines and editing files from windows. Or worse (here talking by unfortunate direct experience) big merchants with IT managers too retarded to understand Linux OSX and Windows have all different purposes that can't overlap, still forcing their developers to work on such projects from Windows machines.

That's the real problem. You have a 20k files project, unix based, updated with a broken file AND written from a Windows machine. And patching it is a nightmare because no one knows how to put up with that...

So, to save you time,

here some pointers.

File generated with windows, have a dos filesystem, which terminates lines with CR + LF (ASCII HEX 0d + 0a)

image(41)

while unix has only 0a. So, either A. convert line endings in the patch file to the original (wrong) format, or B. before each line in the patch, you add CR character (^M).

Assuming you have broken-code.txt to patch, and you write broken-code.txt.patched,

Commands file, dos2unix, unix2dos, diff | cat -t are the ones that can help.

On Mac you need to install some of them.

brew install dos2unix unix2dos

file will give you information about the encoding (example, where I edited from Mac broken-code.txt.patched)

➜ $: file broken-code.txt        
broken-code.txt: PHP script text, ASCII text, with CRLF, CR line terminators
➜ $: broken-code.txt.patched
broken-code.txt.patched: PHP script text, ASCII text

Show the real difference with cat -t

diff broken-code.txt broken-code.txt.patched | cat -t
Screenshot 2021-01-28 at 12 18 19

The problem is when you create a patch file, this will forget writing the bad line ending (microsoft).

So, ideally, once you've created your patch file, 

diff -Naur broken-code.txt broken-code.txt.patched>fix-broken-code.patch

You then, either convert it back to windows with unix2dos fix-broken-code.patch (option A),

or (option B) you add a ^M at the end of each involved line with vim (once in editing mode, CTRL+V CTRL+M)

To close the comment, the point is that by 'having this problem', it allows you to spot the originating problem (windows machine, wrong encoding, on a unix based project).

allanpaiste commented 3 years ago

Great explanation @angelomaragna!

I guess one thing to aid the situation would be to at least give better feedback in form of an error where the plugin would just notify that the targeted file and patch have mismatching line-endings and then recommend ways forward.

As for the different flag configurations per platform, then there's always the possibility to split the configuration of the patcher by using the configuration, which does not solve this by default for everyone, but would allow certain mixed-os projects teams to have less of a hassle with this:

https://github.com/vaimo/composer-patches/blob/master/docs/CONFIGURATION.md#overrides-based-on-os-type

puggan commented 3 years ago

One way around this, could be to allow the composer-config to include a list of files to run dos2unix on, and execute this on the files before applying the patches.

peterjaap commented 3 years ago

Thanks @angelomaragna, I ran into this again and your option B worked perfectly (which was wat @puggan already said as well but I didn't know how to do it).

IMHO this issue can be closed since it indeed has nothing to do with the vaimo/composer-patches package.

allanpaiste commented 3 years ago

I guess we could still have some kind of hint, etc added when encountering this to make it easier to solve :)