I don't know if it was meant to be a dig but I hope you don't think the fact that Git was a big advancement on SVN means it doesn't deserve any criticism.
It's very widely remarked that the Git CLI is pretty miserable, and as soon as a better (so I hear) alternative comes along they suddenly realise and start improving it... This happens all the time in software.
Some software has crap UX or missing obvious features (e.g. comments in package.json). People try and improve it but are rebuffed because the maintainers claim it's fine as it is. Effort goes elsewhere to a competitor project which starts to attract users. Maintains of the original project have a sudden and coincidental change of heart!
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.
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.)
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.
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?
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.
Yep. Nothing I hate more than some trivial formatting error that could easily fix itself halting CI. I am all for consistent formatting and linting, I just think it should be silently handled without fuss.
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.
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.
Yes, and I hate it so, so much, and frankly don’t get the appeal. You want one-click installation of hooks? Bundle a shell script called run_first.sh that symlinks the hooks into .git.
Ok well what about when I pay you and give you a local machine to work on?
Can I pay you to run hooks on the work machine I own because it saves a lot of work on the share build machines? Can we talk about making that situation less error prone?
I agree with the other replies saying to just run the checks in CI and have the CI error message mention how to install the pre-commit hook.
I'm glad cloning a repo doesn't automatically install hooks since I strongly dislike them: I often use Git commands in the terminal but sometimes I use the VS Code UI to commit, and it's extremely frustrating when simply creating a commit runs for several seconds because of some pre-commit hook.
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.
Those new git history commands will save me an average of maybe a minute a day, but it's still definitely handy nonetheless! After 2 months, that's an hour back!
The git log -L change is nice to see as well. Anything that makes git more filterable gets my vote.
I do almost no direct git work myself these days. Using claude in Conductor. Working on a team. I'll tell claude what do do in git sometimes, but there doesn't seem to be much need to do it myself anymore, even with complicated rebases, reflogs, etc.
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
If this is meant to be a dig, you should keep in mind how much jj owes to git.
I don't know if it was meant to be a dig but I hope you don't think the fact that Git was a big advancement on SVN means it doesn't deserve any criticism.
It's very widely remarked that the Git CLI is pretty miserable, and as soon as a better (so I hear) alternative comes along they suddenly realise and start improving it... This happens all the time in software.
Some software has crap UX or missing obvious features (e.g. comments in package.json). People try and improve it but are rebuffed because the maintainers claim it's fine as it is. Effort goes elsewhere to a competitor project which starts to attract users. Maintains of the original project have a sudden and coincidental change of heart!
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?
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.
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.)
in jj the history has mutable and immutable commits.
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.
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.
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.
Yep. Nothing I hate more than some trivial formatting error that could easily fix itself halting CI. I am all for consistent formatting and linting, I just think it should be silently handled without fuss.
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.
We do run the linter on CI as well, but I think our comitters would get faster feedback if they ran those checks locally.
Well you can tell them to please enable hooks in the PR guidelines, but you cannot really police what they do or don't run on their own machines.
You can issue installation instructions on linter failure in CI.
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.
Yes, and I hate it so, so much, and frankly don’t get the appeal. You want one-click installation of hooks? Bundle a shell script called run_first.sh that symlinks the hooks into .git.
The pre-commit tool does way more than that. For example the clang-format hook will download and run a specific version of clang-format.
In PHP, an established tool is adding GrumPHP [0] to your dependencies.
It will then handle git hooks on each commit via composer script by default (but can be omitted per commit).
[0] https://github.com/phpro/grumphp
I don't want you to run arbitrary hooks on my machine. As with CI/CD... your hooks should simply point to a script instead
Ok well what about when I pay you and give you a local machine to work on?
Can I pay you to run hooks on the work machine I own because it saves a lot of work on the share build machines? Can we talk about making that situation less error prone?
I agree with the other replies saying to just run the checks in CI and have the CI error message mention how to install the pre-commit hook.
I'm glad cloning a repo doesn't automatically install hooks since I strongly dislike them: I often use Git commands in the terminal but sometimes I use the VS Code UI to commit, and it's extremely frustrating when simply creating a commit runs for several seconds because of some pre-commit hook.
There’s almost certainly a way to make VS Code use --no-verify.
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.
My project needs other things on setup as well, so I just have a setup script in my repo. `mv hooks/foo .git/hooks` is then just yet another step.
I add an autogen.sh script to all my repositories that does things like this as it's first action.
You can also set up a central git template repository, so hooks get automatically added into every repository you clone
`git history reword` is great. Using `git rebase -i` just to fix a spelling error is overkill and doesn’t actually do what I want.
Those new git history commands will save me an average of maybe a minute a day, but it's still definitely handy nonetheless! After 2 months, that's an hour back!
The git log -L change is nice to see as well. Anything that makes git more filterable gets my vote.
The new additions to `git add -p` seem pretty neat. Staging changes with `-p` is seriously underrated!
I do almost no direct git work myself these days. Using claude in Conductor. Working on a team. I'll tell claude what do do in git sometimes, but there doesn't seem to be much need to do it myself anymore, even with complicated rebases, reflogs, etc.
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