| ▲ | jiehong 4 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 |
|
| ▲ | jiehong 3 hours ago | parent [-] |
| 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 3 hours ago | parent [-] | | 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 an hour ago | parent | next [-] | | 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. | |
| ▲ | stavros 2 hours ago | parent | prev [-] | | I don't think you have to, you can run the integrated watcher, no? |
|
|
