Comment by jiehong

Comment by jiehong 7 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

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.

Reply View 0 replies

[removed] an hour ago

[deleted]

Reply View 0 replies

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!

Reply View 3 replies

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

Reply View | 2 replies
- 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.
  
  Reply View | 0 replies
- stavros 5 hours ago
  
  I don't think you have to, you can run the integrated watcher, no?
  
  Reply View | 0 replies