I'll consider avoiding jj because of this, personally.

> In jj, everything rewrites the history (...)

Surely that isn't true, otherwise it would be completely unusable for auditing.

I think this is cluttering git with a bunch of special-case commands when rebase is all you need. Next thing you know, people will say we need to drop git because there are 5 ways to do everything.

> 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.

This command is implemented by just one single (but prolific) contributor. His own idea.

>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.

I don't think these claims have merit, for the most part. More often than not, people just don't take any time to learn git, then get on a soapbox about it.

If you think these commands are worthwhile, by all means use them. I happen to think git rebase is all you need. Giving people crutches to avoid using it just delays their enlightenment. But not everyone reaches enlightenment, it's true.

I don't think jj adds anything compelling over git either. But different strokes for different folks...

> It's very widely remarked that the Git CLI is pretty miserable, (...)

You hear some very vocal critics expressing hyperbolic personal opinions on the topic, but I find that in the majority of the cases the opinions aren't objective or grounded on reality. It's just people whining.

The litmus test is asking what is the worst example of this "pretty miserable" CLI they talk about. More often than not it's just baseless nitpicking. I recommend you give the litmus test a try to see how far this myth flies.

> Why waste a round trip, build time, loss of flow and CI machine queue wait time when you can catch things early?

Because we want to be sure that the checks have passed, and that they have passed in a clean environment.

Contributors can, in addition, use git hooks, or run tests in watch mode, or use their IDE.

Also it's annoying to have slow git hooks if you commit often.

You're looking for a technological solution for a human problem.

Automatically running arbitrary code from random repositories is a Really Bad Idea, so Git will almost certainly never auto-install pre-commit hooks. Just mention it in the README and run a checker in CI to confirm they are using it, it really isn't that difficult.

People wasting 2 minutes of their own time once during their first contribution because they didn't read the README is not that big of a deal. What's next, you want a script to automatically sign a project's legally-binding CLA on checkout?

Local hooks are just a convenience. CI checks are assurances, you have to have them.

If one hates the round-trip he/she will adopt hooks quickly.

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.

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.

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.

Tools growing unexpected code execution is how we keep having problems with secrets and other important things being stolen. If you add this feature to git, generally, then anybody cloning a git repo is going to have to deal with the fact that `git clone` might run arbitrary code. `git clone` is like `cp`. Do you want `cp` to unexpectedly run code? It should never do that.

Why force git to be a build tool?

Just document how to execute the scripts/checks that will be used by ci. Provide a simple script in the repo that folks can intentionally execute.

Yes that’s perfectly fine of course. But these days that’s not so common