I have always had this problem with hooks and new contributors: since hooks don't run by default if you just clone the repository, my open source projects get many PRs from new contributors that did not run the linting and commit hooks. I understand there's a security reason for this but what workflows have worked best for you to get everyone to run the hooks? And do you think the new config-based hooks can help new contributors?
As well, not instead. Just add `pre-commit run -a` to your CI. Job done.
It's still annoying for new contributors though because they might not know how to set up pre-commit (which was quite a pain until recently because it's written in Python).
To clear up any confusion, Git runs pre-commit hooks, and they can be written in any programming language. There's a completely separate and independent project that gave itself the confusing "pre-commit" name, and it is written in Python. This project aims to make it easier to configure pre-commit hooks. An alternative to it is "prek", written in Rust.
autoformatter and autofix linter results can be committed and pushed by CI into the PR branch itself. this is a pain sometimes, but as a repo owner it should protect your sanity.
I just add a check workflow that test that the files are well formatted and linted. If it passes, one of the key things I check are changes to the configuration. Some tools allows for bypass comments, so I keep an eye out for those too.
The approach some JS projects have taken is to use Husky, which automatically sets up the git hooks when you install the project's dependencies during development.
describe is also the command you can use to edit the commit message of the change you're currently drafting. In jj there's no staging area, every modification to the working tree immediately gets integrated into the current commit. (This means if you have no diff in your working tree, you're actually on an empty commit.)
jj describe gives a name to a commit. In jj, everything rewrites the history, so there's no real point in calling it out in the command name since it's just the default behavior.
Not really familiar too, but jj has everything committed by default (no index, staging area, and uncommitted changes). You use ‘jj new’ to stop adding changes to the current commit.
‘jj describe’ lets you add a message to a commit as it’s not there by default.
The new additions to `git add -p` seem pretty neat. Staging changes with `-p` is seriously underrated!
I have always had this problem with hooks and new contributors: since hooks don't run by default if you just clone the repository, my open source projects get many PRs from new contributors that did not run the linting and commit hooks. I understand there's a security reason for this but what workflows have worked best for you to get everyone to run the hooks? And do you think the new config-based hooks can help new contributors?
> what workflows have worked best for you to get everyone to run the hooks
By running the linters and any other checks on CI instead.
We do run the linter on CI as well, but I think our comitters would get faster feedback if they ran those checks locally.
As well, not instead. Just add `pre-commit run -a` to your CI. Job done.
It's still annoying for new contributors though because they might not know how to set up pre-commit (which was quite a pain until recently because it's written in Python).
To clear up any confusion, Git runs pre-commit hooks, and they can be written in any programming language. There's a completely separate and independent project that gave itself the confusing "pre-commit" name, and it is written in Python. This project aims to make it easier to configure pre-commit hooks. An alternative to it is "prek", written in Rust.
autoformatter and autofix linter results can be committed and pushed by CI into the PR branch itself. this is a pain sometimes, but as a repo owner it should protect your sanity.
I just add a check workflow that test that the files are well formatted and linted. If it passes, one of the key things I check are changes to the configuration. Some tools allows for bypass comments, so I keep an eye out for those too.
The approach some JS projects have taken is to use Husky, which automatically sets up the git hooks when you install the project's dependencies during development.
Nice to see some seemingly jujutsu inspired features getting into Git core.
https://git-scm.com/docs/git-historyhttps://www.jj-vcs.dev/latest/cli-reference/#jj-describe
https://www.jj-vcs.dev/latest/cli-reference/#jj-split
Not familiar with jj and don't want to get into bike shedding, but how is describe supposed to be a good name for history rewrites?
describe is also the command you can use to edit the commit message of the change you're currently drafting. In jj there's no staging area, every modification to the working tree immediately gets integrated into the current commit. (This means if you have no diff in your working tree, you're actually on an empty commit.)
jj describe gives a name to a commit. In jj, everything rewrites the history, so there's no real point in calling it out in the command name since it's just the default behavior.
Not really familiar too, but jj has everything committed by default (no index, staging area, and uncommitted changes). You use ‘jj new’ to stop adding changes to the current commit.
‘jj describe’ lets you add a message to a commit as it’s not there by default.
the new git history command seems to be useful for quick reword, altho since i use lazygit/magit i don't really see much of a problem to me
Wish reword took a commit range though