Comment by jiehong

8 hours ago

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

6 comments

jiehong

Reply
chrisweekly  2 hours ago

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.

jiehong  7 hours ago

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!

  • wrs  7 hours ago

    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.)

    • sfink  5 hours ago

      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.