Cameron Eagans

@mfb Can you please take a look at #447 (in particular, `src/Patcher/*`) and let me know if I've captured what needs captured?

(for context, 2.x is essentially a rewrite and it breaks a _ton_ of things out of the main plugin so that they're individually testable)

Great! I'm going to close this then and focus on getting 2.x out the door as quickly as possible. (also thank you for the review -- super helpful)

Probably not going to do this. The order that patches are applied to a dependency is not something that can just be changed in most cases.

This is a result of the plugin attempting to guess patch depth. patch depth is no longer guessed: either use the defaults or explicitly say what you want. `main` is...

https://unix.stackexchange.com/questions/26501/when-patching-whats-the-difference-between-arguments-p0-and-p1 Just want to be clear: the changes I mentioned in my last reply are only available on the `main` branch, not in the `1.x` version of the plugin. There...

`main` doesn't do dependency patch resolution out of the box anymore.

`main` allows you to specify depth on a per-patch basis now. I'll be adding the ability to specify a default per-package in the next day or two.

`main` is now very flexible wrt patch depth. You can define it in a number of ways: * Per-patch in the patch definition * (coming soon) Per-package in your composer.json...

Probably not going to merge this into 1.x, but reproducible builds using a lock file is something that I want to explicitly support in 2.x. Keep an eye on #447...