lint-staged loses the MERGE_HEAD while stashing backups, so the current behaviour breaks merge conflict resolution. Solution is to manually check, save, and restore the MERGE_HEAD during runtime. This should be fixed and the test adjusted for successful run

Git diff completely ignores new, untracked files, but they can be read/written separately

BREAKING CHANGE: Prior to version 10, tasks had to manually include `git add` as the final step. This behavior has been integrated into lint-staged itself in order to prevent race conditions with multiple tasks editing the same files. If lint-staged detects `git add` in task configurations, it will show a warning in the console. Please remove `git add` from your configuration after upgrading.

…re stashed"

This reverts commit 869bac6.

…ment length (#732)

* feat: split tasks into chunks to support shells with limited max argument length

* refactor: use a function for getting max arg lenth

* refactor: simplify spreading of listrTasks into main runner tasks

… cases

# Conflicts:
#	bin/lint-staged
#	src/index.js
#	src/runAll.js

BREAKING CHANGE: Node.js v8 is no longer supported because it will reach EOL on 2019-12-31

Using `git add .` does not work when an unrelated 3rd-party makes a file edit while lint-staged is running tasks. This change at least limits adding of modifications to those files that originally had staged changes. Unfortunately we have no way of detecting if a 3rd-party edits the same file.

…rors

…ed (#762)

BREAKING CHANGE: Previously, lint-staged would allow empty commits in the situation where a linter task like "prettier --write" reverts all staged changes automatically. Now the default behaviour is to throw an error with a helpful warning message. The --allow empty option can be used to allow empty commits, or `allowEmpty: true` for the Node.js API.

# Conflicts:
#	package.json

# Conflicts:
#	README.md