Better docs

Author: pinkeen

README.md

@@ -41,7 +41,7 @@ It's (kind-of) an alternative to two other great plugins (differences will becom
 _<sup>1</sup> Root package patching is the exception, please see [applying patches to root package](docs/usage.md#applying-patches-to-root-package-root-project-folder) in usage docs._
 
 
-### Some feature hilights
+## Feature description
 
  - Apply patches from dedicated composer packages (package your patchset!).
  - Each patch can have a version constraint (composer semver) checked against the target package.
@@ -63,7 +63,19 @@ _<sup>1</sup> Root package patching is the exception, please see [applying patch
 
    Double composer update/install for build is not necessary.
 
-### Chicken or egg problem
+## Use Git for applying patches
+
+By default the library will try to use the `patch` command if not available and fall back to `git` otherwise.
+You can force using git for each patch (see: [Usage Documentation](docs/usage.md)).
+
+There were some problems using `git apply` reported in other plugins for packages that were not installed
+as source (did not have a git repo; `.git` dir). I was not able to reproduce this problem with git 2.X - however -
+a workaround for this potential problem has been implemented:
+
+    - If the target package has `.git` directory, then the patches are applied relative to target package root
+    - If no git repo in target package then patches are applied from root project directory
+   
+## Chicken or egg problem
 
 Patching via composer plugin has one big problem - you cannot catch all events on the first install.
 Furthermore applying patches on package install/remove is very error prone as you can never predict
@@ -79,7 +91,7 @@ of your project then you should patch the root package because the patch applica
 plugins have done their work so patching source files in vendor will have no effect.**
 
 
-### No remote patches
+## Why no remote patches
 
  This plugin will not download patches from external sources directly (http). I consider this a bad practice and will
  never support it. I won't even comment on downloading patches using unencrypted connection without SHA check. Also what

docs/testing.md

@@ -4,10 +4,10 @@
 
 This plugin uses a special sandbox which allows it to run composer as a separate process during testing.
 
-A fake local packagist repository is created from [package definitions](tests/Functional/Fixtures/Packages) 
+A fake local packagist repository is created from [package definitions](/tests/Functional/Fixtures/Packages) 
 for the purpose of testing by using internally [Satis](https://github.com/composer/satis) as a library.
 
-See the [ComposerSandbox](tests/Functional/Fixtures/ComposerSandbox.php) class for the details.
+See the [ComposerSandbox](/tests/Functional/Fixtures/ComposerSandbox.php) class for the details.
 
 ## Running tests
 

docs/usage.md

@@ -56,7 +56,7 @@ _Use this way to easily distribute your patchset and use it in multiple projects
 
 ## Define patches in your root package
 
-# Composer json configuration reference 
+# JSON configuration reference 
 
 ## Patch properties
 
@@ -84,6 +84,15 @@ This has the same effect as the `-p{x}` switch of the patch command, where `{x}`
 
 For 99% of the patches this will be the default `1`. Set this only if your patch was generated in some non-standard way.
 
+### `method` (string, default: `"patch"`)
+
+There are two methods of application: `patch` and `git`.
+
+By default the library will attempt to use the `patch` binary and fall back to `git apply` if not available.
+
+If you want to force using `git apply` for patches that are compatible only with `git` you can do so
+with this parameter on patch level.
+
 # Notable use-cases
 
 ## Applying patches to root package (root project folder)
@@ -97,3 +106,4 @@ project manually. The plugin will warn you when this is the case but will not fa
 to apply any new root package patches though.
 
 __New patches will be applied to the root package but then _application order_ is not guaranteed.__
+