zlacker

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+(OP)
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+r3
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+y7
I don't think you have to, you can run the integrated watcher, no?

>>wrs+y7
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.

>>jiehon+(OP)
I prefer to configure my IDE to apply precisely the same linting and formatting rules as used for commits and in CI. Save a file, see the results, nothing changes between save, commit, stage, push, PR, merge.

>>jiehon+(OP)
> I personally can't stand my git commit (...) or to fail.

But that's the whole point of locally checking the code, no? Would you prefer to commit broken things, fix them and then rebase and squash each time?

>>jiehon+(OP)
> I personally can't stand my git commit command to be slow or to fail.

I feel the same way but you can have hooks run on pre-push instead of pre-commit. This way you can freely make your commits in peace and then do your cleanup once afterwards, at push time.