-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate with https://pre-commit.com/ #405
Comments
In case its useful, a collection of useful https://pre-commit.com/ hooks is here: https://github.com/google/pre-commit-tool-hooks Maybe some even useful for working with this repo! =D |
I looked into this a bit, and I've found two potential ways to interface with pre-commit. The first one is to use the The other one is to pass it an explicit list of files with
There's one hook that's not behaving well (darker), but that's because the program itself is looking at the git index, so I might have to find another trick to convince it to do what I want. |
I think A bigger problem is that the PS. |
I would argue that the general problem here is not "running hooks" but "running commands on each commit". One other example is that you might want to run tests on all commits in your stack and get feedback on which commits are passing. For git-branchless, I wanted to recreate https://github.com/spotify/git-test to this end, but also add some modes that amend the commit with any working copy changes. The execution strategy could be selected by the user as one of "working copy" or "use up to X worktrees" or "use up to X VFS checkouts". EDIT: by the way, I did recreate |
As mentioned in Discord: https://discord.com/channels/968932220549103686/969829516539228222/1047922968543637504 I'd like to implement a |
Is there any status on Sounds like quite a few steps before something like pre-commit.com integration could be ready to use. Any baby steps or prototyping that could be done while work on |
@PhilipMetzger has started designing the feature. There's been quite a bit of discussion on our Discord chat. We haven't quite decided how it will work yet, and we haven't talked about pre-commit.com integration specifically, but I think we've pretty much decided that the |
This adds the `run` command as described in the doc. The command is hidden for now, to allow in-tree development. The next steps are: 1. Move it to `run.rs` 2. Find a good backend trait 3. Implement the workers Initial progress on jj-vcs#1869 and jj-vcs#405
Just checking in since I hit this lack of pre-commit support again today. Have we gotten any closer to landing a solution? |
I'm slowly inching closer to the implementation of |
Awesome, as long as I can still have hope it'll land eventually!
Would that generally look something like: $ . .git/hooks/pre-commit && jj describe ? If I can find some one-liner workarounds at least I won't have to choose between using jj and having hooks applied, when I'm working in projects that have important hooks. |
You'll probably need something like https://gist.github.com/thoughtpolice/8f2fd36ae17cd11b8e7bd93a70e31ad6 but instead of calling Gerrit's hooks (see the |
Thanks! And how'd you know I was dealing with Gerrit hooks, just a lucky guess? |
It is the most common question in relation with |
In principle this trait is a layer above an actual VFS, but should be enough to start working with them. It's responsible for caching and managing working-copies which are stored locally or on a remote. The plan is that `jj run` will query it to request working copies, which it then uses. This checks the third checkmark in #1869. Progress on #1869 and #405 cc @martinvonz, @hooper, @kevincliao, @arxanas
It sounds like things are going in a different direction than commit hooks but, just in case, I wanted to bring up a slightly different use case for a commit verification hook: verifying commit messages. I use my tool committed with pre-commit today. It is annoying that it rejects my commit message and I have to write it all over again. Seeing how merge conflicts work, it'd be great if a verification hook system could track the status and clear it when fixed or allow the user to explicitly force the status to be cleared. |
In principle this trait is a layer above an actual VFS, but should be enough to start working with them. It's responsible for caching and managing working-copies which are stored locally or on a remote. The plan is that `jj run` will query it to request working copies, which it then uses. The client is coming with the workqueue which is step 4 in #1869. This checks the third checkmark in #1869. Progress on #1869 and #405 cc @martinvonz, @hooper, @kevincliao, @arxanas
In principle this trait is a layer above an actual VFS, but should be enough to start working with them. It's responsible for caching and managing working-copies which are stored locally or on a remote. The plan is that `jj run` will query it to request working copies, which it then uses. The client is coming with the workqueue which is step 4 in jj-vcs#1869. This checks the third checkmark in jj-vcs#1869. Progress on jj-vcs#1869 and jj-vcs#405 cc @martinvonz, @hooper, @kevincliao, @arxanas
In principle this trait is a layer above an actual VFS, but should be enough to start working with them. It's responsible for caching and managing working-copies which are stored locally or on a remote. The plan is that `jj run` will query it to request working copies, which it then uses. The client is coming with the workqueue which is step 4 in jj-vcs#1869. This checks the third checkmark in jj-vcs#1869. Progress on jj-vcs#1869 and jj-vcs#405 cc @martinvonz, @hooper, @kevincliao, @arxanas
I uses git-hooks.nix, which can generate libgit2 appears to support |
Description
I don't think I had seen https://pre-commit.com/ until @chandlerc linked to it. It would be really nice to integrate with that somehow. I currently have a long command for running Clippy and
rustfmt
on my commits. It would be better if we could use pre-commit.com for sharing that between users and making it easy to run. I don't yet know how it would work.Mercurial's fix extension seems closely related. IIUC, pre-commit.com runs all its checks in the working copy (possibly after stashing any unstaged changes), so that's a big difference compared to
hg fix
. I think it would be nice if we could run the pre-commits on all commits in parallel just likehg fix
does, but that's slow to do if the working copy is large because we'd need to create a working copy for each commit (unless/until we can expose a commit in a virtual file system). That's whyhg fix
doesn't do it. A good start might be if we can figure out a way of running the pre-commit.com checks in the working copy.The text was updated successfully, but these errors were encountered: