Under Cygwin Windows-style paths are used

[ds300]

Under Cygwin Windows-style paths are used

[dmos62]

I wrote a minimalistic alternative[0]. You might find it interesting. It's in the form of a cli tool. Wrote a brief overview there. [0] https://gist.github.com/dmos62/5ac03373328a9d9cdc3288185f531547

…

On 9/19/17, David Sheldrick ***@***.***> wrote: Oh, and thanks for the report, I'm looking into it now :) -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #18 (comment)

[dmos62]

Instead of working around host platform's peculiarities, would it make sense to replace git with a js implementation of diff-patch?

[ds300]

Maybe. I looked into it a couple of weeks ago when fixing some windows support issue. It seemed like overkill for that but in the long run might be worth it. But then again it would need a lot more code to be written and tested, whereas fixing forward/back slash usage is not much code, just a bit fiddly.

[ds300]

Oh, and thanks for the report, I'm looking into it now :)

[ds300]

That's awesome! Really clean implementation. Using hashes is a cool idea. patch-package does dry runs to detect whether the patch was already applied, which is likely a bit more expensive.

[dmos62]

What information does a dry run give? Is it that the underlying patch implementation can tell that the patch was already applied? The really cool thing about patch-package is that it automatically detects the changes made. With my implementation, I couldn't think of a simple way to get the original file from npm, so the user, while making changes, has to keep a copy of the original, or keep the changed file somewhere else.

…

On 9/20/17, David Sheldrick ***@***.***> wrote: That's awesome! Really clean implementation. Using hashes is a cool idea. patch-package does dry runs to detect whether the patch was already applied, which is likely a bit more expensive. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #18 (comment)

[ds300]

Is it that the underlying patch
implementation can tell that the patch was already applied?

Kinda. If the dry run fails, then it does a "reverse" patch dry run, which is like assuming the patch was already applied and trying to unapply the patch. If that "reverse" patch is successful, then it means the patch was already applied. This is more complicated and slower than hashing, but also allows the contents of the file to change in independent unaffected areas, e.g. if the package is updated but the patch is still needed.

[dmos62]

I was searching for something like this among the JS patch implementations, but couldn't find anything more advanced than Neil Fraser's diff-match-patch [0], even which, in this case, doesn't offer anything more than the most basic implementation. [0] https://code.google.com/archive/p/google-diff-match-patch

…

On 9/21/17, David Sheldrick ***@***.***> wrote: > Is it that the underlying patch implementation can tell that the patch was already applied? Kinda. If the dry run fails, then it does a "reverse" patch dry run, which is like assuming the patch was already applied and trying to unapply the patch. If that "reverse" patch is successful, then it means the patch *was* already applied. This is more complicated and slower than hashing, but also allows the contents of the file to change in independent unaffected areas, e.g. if the package is updated but the patch is still needed. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #18 (comment)

[ds300]

Apologies for the delay. I had a chance to look into this today. Couldn't reproduce the issue on Windows Server 2016 with latest Cygwin, but have tried enforcing use of unix-style paths everywhere and it seems to be OK. Will test some more tomorrow and publish a new version if all goes well.

[ds300]

Testing went well. v3.4.6 might fix this. Let me know if you try it out.

[ds300]

Haven't been able to reproduce this issue, and have changed all paths to be unix-style, so I'm closing this due to inactivity. Feel free to reopen it if you find you're still encountering the issue.