Comment by dpc_01234

Just because the hooks have the label "pre-commit" doesn't mean you have to run them before committing :).

I, too, want checks per change in jj -- but (in part because I need to work with people who are still using git) I need to still be able to use the same checks even if I'm not running them at the same point in the commit cycle.

So I have an alias, `jj pre-commit`, that I run when I want to validate my commits. And another, `jj pre-commit-branch`, that runs on a well-defined set of commits relative to @. They do use `pre-commit` internally, so I'm staying compatible with git users' use of the `pre-commit` tool.

What I can't yet do is run the checks in the background or store the check status in jj's data store. I do store the tree-ish of passing checks though, so it's really quick to re-run.

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

That's a great idea, and I was just thinking about how it would pair with self hosted CI of some type.

Basically what I would want is write a commit (because I want to commit early and often) then run the lint (and tests) in a sandboxed environment. if they pass, great. if they fail and HERAD has moved ahead of the failing commit, create a "FIXME" branch off the failure. back on main or whatever branch head was pointed at, if tests start passing, you probably never need to revisit the failure.

I want to know about local test failures before I push to remote with full CI.

automatic branching and workflow stuff is optional. the core idea is great.

I like this approach. Something related I've been tinkering with are "protected bookmarks" - you declare what bookmarks (main, etc) are protected in your config.toml and the normal `jj bookmark` commands that change the bookmark pointer will fail, unless you pass a flag. So in your local "CI" script you can do `jj bookmark set main -r@ --allow-protected` iff the tests/lints pass. Pairs well with workspaces and something that runs a local CI (like a watcher/other automated process).

I haven't yet submitted it to upstream for design discussion, but I pushed up my branch[1]. You can also declare a revset that the target revision must match, for extra belts and suspenders (eg., '~conflicts()')

[1] https://github.com/paulsmith/jj/tree/protected-bookmarks

Looks very interesting, I fully agree that running CI locally is viable.

But what I didn't pick up for a quick scan of README is best pattern for integrating with git. Do you expect users to manually run (a script calling) selfci manually or is it hooked up to git or similar? When does the merge hooks come into play? Do you ask selfci to merge?

That looks really cool! I've been looking for a more thought-out approach to hooks on JJ, I'll dig into this. Do you have any other higher level architecture/overview documentation other than what is in that repo? It has a sense of "you should already know what this does" from the documentation as is.

Also, how do you like Radicle?

I want multilayered reactive DAG ala Maya for source code

Being visible is useful, this is probably better suited for an ide than a hook or a daemon.

git ls-files | entr pre-commit