mirror of
https://github.com/pre-commit/pre-commit.git
synced 2026-02-17 08:14:42 +04:00
40c83283d6
When using [Sapling SCM](https://sapling-scm.com/) with a Git repository, precommit expectedly fails today because it shells out to `git` to get the list of modified files in the working copy. In a Sapling clone of a Git repository, these calls will fail. While most of the logic in precommit that deals with talking to Git today is encapsulated in `git.py`, calls to `git` are sprinkled throughout the project and are called directly. In order to support alternative SCMs, such as Sapling, ideally there would be a more generic "SCM" interface that business logic would call into with both Git and Sapling implementations. Though this PR does not attempt to introduce such an interface. Instead, it is just a basic PoC to provide evidence that something like this could be made to work. For the moment, it takes a shortcut and simply sprinkles "if Sapling" checks in `git.py` in enough places that I could get precommit to run in a Sapling working copy in the simple case where I had only one file modified locally. My higher-level question is whether the precommit project would be open to accepting changes to support Sapling, either via the introduction of an SCM-agnostic interface or some other means. |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| autoupdate.py | ||
| clean.py | ||
| gc.py | ||
| hook_impl.py | ||
| init_templatedir.py | ||
| install_uninstall.py | ||
| migrate_config.py | ||
| run.py | ||
| sample_config.py | ||
| try_repo.py | ||
| validate_config.py | ||
| validate_manifest.py | ||