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
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
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.
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!
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.)
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.
I don't think you have to, you can run the integrated watcher, no?