[rfc] Support Sapling (alternative SCM) when using precommit

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.
This commit is contained in:
Michael Bolin 2024-03-01 15:35:57 -08:00
parent 7b868c3508
commit 40c83283d6
3 changed files with 87 additions and 4 deletions

View file

@ -322,6 +322,10 @@ def _run_hooks(
def _has_unmerged_paths() -> bool:
if git.is_sapling():
# FIXME: Implement this properly.
return False
_, stdout, _ = cmd_output_b('git', 'ls-files', '--unmerged')
return bool(stdout.strip())