zlacker

>>fortui+(OP)
BTW. Pre-commit hooks are the wrong way to go about this stuff.

I'm advocating for JJ to build a proper daemon that runs "checks" per change in the background. So you don't run pre-commit checks when committing. They just happen in the background, and when by the time you get to sharing your changes, you get all the things verified for you for each change/commit, effortlessly without you wasting time or needing to do anything special.

I have something a bit like that implemented in SelfCI (a minimalistic local-first Unix-philosophy-abiding CI) https://app.radicle.xyz/nodes/radicle.dpc.pw/rad%3Az2tDzYbAX... and it replaced my use of pre-commit hooks entirely. And users already told me that it does feel like commit hooks done right.

>>dpc_01+fy
Yep, I think a watcher is better suited [0] to trigger on file changes.

I personally can't stand my git commit command to be slow or to fail.

[0]: such as https://github.com/watchexec/watchexec

>>jiehon+pU
To myself: sometimes I think the background process should be committing for me automatically each time a new working set exists, and I should only rebase and squash before pushing.

That’s reversing the flow of control, but might be workable!

>>jiehon+QX
jj already pretty much does that with the oplog. A consistent way of making new snapshots in the background would be nice though. (Currently you have to run a jj command — any jj command — to capture the working directory.)

>>wrs+X11
You can configure watchman to do it. `fsmonitor.watchman.register-snapshot-trigger = true`

I don't recommend it, though, at least not on large repositories. Too much opportunity to collide with command-line jj write operations.