Does jj have git hook support?

[zygoloid]

Does jj have support for either git hooks or a similar mechanism?

https://github.com/martinvonz/jj/blob/main/docs/git-compatibility.md doesn't seem to mention this one way or the other, so it'd be nice if it were discussed there even if the answer is no for now.

[martinvonz]

There's no support for git hooks yet. Good point about updating the docs. I'll send a PR for that.

Because the workflow in jj is quite different, some of the hooks don't seem to make much sense. For example, because we implicitly create commits from the working copy and/or without touching the working copy (e.g. when you change the description of an ancestor commit), Git's pre-commit hook would usually not make sense. I think even Git itself is considering skipping the pre-commit hook when rebasing, once they start doing it without touching the working copy. The post-commit doesn't make much sense either, since it also relies on HEAD being for the just-created commit.

We could probably call the prepare-commit-msg hook. However, if the hook tries to inspect the working copy or Git's HEAD, it will typically not do what you want. Also, I just experimented a bit with it and the third "SHA1" argument it gets doesn't seem to actually be a SHA1 (it's been empty or the string "HEAD" in my experimentation). So maybe it only makes sense for jj to call it when the working copy is colocated with Git (i.e. created by jj init --git-repo=.) and we're snapshotting the working copy. That may be true for most hooks.

Which hook(s) do you miss having support for?

FWIW, I've planned to eventually add native (i.e. not Git-specific) hooks. There would be at least a transaction-level hook, which would let you inspect and approve the changes in a transaction (there's typically one transaction per command, plus maybe one more for snapshotting the working copy).

[chandlerc]

For myself at least, I'm not so much looking for support of all the hooks, but more the hooks that make sense in the new workflow. Ideally, supporting the same hook interface (so existing hooks can be used), provided they fit into the meaningful slot in the workflow like you describe for prepare-commit-msg. But no idea how to bridge the API gap if it exists.

For me, the hooks I care most about are things like https://pre-commit.com/ -- while it is called "pre-commit", it isn't actually specific to the "pre-commit" hook in Git. Personally, I most often use it as a pre-push hook.

So selfishly, just having the pre-push hook from pre-commit.com would be pretty helpful for me... but others probably have some other more interesting needs here.

[martinvonz]

I filed #405 for integrating with pre-commit.com in some way. Thanks for pointing me to that.

[ucirello]

Echoing the support to add support to some of the git-hooks. The ones I use that I believe fit well with jj's workflow:

• commit-msg: that allows me to ensure that the message I wrote fits a certain standard.
• pre-push: which I believe should play well with jj git push - unless I am missing something, the push operation between git and jj git push use the same underlying constructs? In my naïveté, they should play well together.

[PhilipMetzger]

Hello thanks for your interest in hooks. See this comment for an analysis of the feasibility of hooks #3577 (comment) in jj. I'm informing you because I'm largely responsible for it (#405, #1869).

[ucirello]

@PhilipMetzger -- thank you for the pointers.

[orimay]

It would've been awesome to have pre-commit hook. Linting/formatting the files that are being committed is an extremely useful feature

[orimay]

Hello! Thanks, I'm aware, but it's aseparate command. I want my VSCode extension to commit my files on save and lint right away. jj fix is no better than running the lint command manually

[carvidoro]

I totally agree.
I'm thinking that, given the difference between how jj and git works, it probably would be more jj-like to run the pre-commit hook on the background (when the user leaves the revision through commit, new, edit, etc) and flag the revision like the "conflict" flag is used.
That said, conflicts in jj cascade through the revisions until they are fixed, so to have something like that would require the hook to be run through all of the revision descendants, and that comes with a possible time (and processing) expense.
Pre-push hook is probably the easier to implement of the two, in this case.

[devurandom]

Since you didn't mention jj fix, I'm thinking you may have missed it. Maybe it's sufficient for your use case. https://docs.jj-vcs.dev/latest/cli-reference/#jj-fix

Thanks for pointing out jj fix!

jj fix is no better than running the lint command manually

I found it to be quite useful to apply formatting to stacked commits. Doing that by running the formatter command manually would have been tedious.

I can imagine it'd also be useful to ensure all commits in a stack pass tests, not just the top commit.

[martinvonz]

jj fix is actually specialized for running tools that don't need access to a working copy. It passes the old contents to the formatter tool on stdin and then get the formatted output from stdout. We have #1869 for adding a jj run command for tools that need access to to a working copy.

[ParadaCarleton]

jj fix is great for cleaning up anything that can automatically be fixed, but isn't quite up to the task of complex lints that require a user to intervene or starting a job like running tests.

[arusahni]

I'd like the ability to add hooks around the workspace lifecycle. My use-case is I have ignored .env files that contain secrets, and I'd like to copy them from the default workspace into the newly-created one. Right now I have a script that I manually invoke to recursively walk the default workspace directory and copy all .env files into the new workspace, but I don't always remember to do that before kicking off a build.

Being able to automatically run something after a workspace create (with input parameters containing the new workspace name/directory) would allow me to automate this.

[daeh]

I've put together a TUI/CLI to handle this sort of thing (jujutsu-gi, or ji). I haven't advertised it yet, but it's a staple part of my workflow and definitely stable enough to take for a spin: https://github.com/daeh/jujutsu-gi

It will give you a TOML config (.config/ji.toml) that lets you define arbitrary shell operations that are executed when the workspace is created. It could call the script you wrote or copy the file(s) directly

[pre-start]
run-my-script = "python3 my_script.py --source {{ default_workspace_path }} --target {{ workspace_path }}"
simple-copy = "cp {{ default_workspace_path }}/.env {{ workspace_path }}/.env"
fancy-copy = "rsync ..."

Or, if the .env also needs to be modified (e.g. there's a path that needs updating), you can generate the file from a template when the workspace is created.

(Currently only macOS is supported, but it'd be a small lift to add linux support if there were people to help test it.)