Cameron Eagans

Can you take a look at https://docs-staging.cweagans.net/composer-patches/usage/configuration/ and let me know if it's along the lines of what you were looking for?

(The configuration options there are specific to 2.x)

It has changed. Right now, main _only_ uses git to apply patches. If the target isn't a git repo, the plugin creates a temporary git repo so that the patch...

`main` works differently now. There has to be at least _some_ patch mechanism available, but `patch` is no longer specifically required. If there aren't any usable patchers, an exception will...

`main` doesn't resolve patches from dependencies anymore, so this may be less of an issue. It also caches patches locally to avoid the scenario where the patch URL is not...

> Any composer plugin directly trying to access URLs on the internet rather than going through Composer's network mechanisms breaks this feature. `1.x` and `main` both now use the Composer...

Let's just close this. #447 has explicit support and detection for different versions of patch. The behavior in 2.x is going to be pretty different: the goal is to get...

In that scenario (even in 1.x), Git should be able to apply the patch properly before it ever gets to `patch`, right? I've made a note to add a test...

Do you have `"config": {"preferred-install": "source"},` in your composer.json? I recommend that in the [readme](https://github.com/cweagans/composer-patches/tree/1.x#usage) specifically so that there is a higher chance of being able to use git for...

> After adding it will look like this. > > > > ``` > > "config": { > > "allow-plugins": { > > "preferred-install": "source", > > "composer/installers": true, >...