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.
it is true. some history is marked immutable by default; in git, everything is mutable by default and you have to add branch protection on the server side. (granted, you can change what is immutable in jj relatively easily, so you shouldn't ignore branch protection if you're using jj exclusively with a git repo, either.)
It's not true, in that sense. Commits in jj are basically the same as commits in git as far as mutability is concerned. But in jj you normally work with changes, rather than commits, and open changes are mutable (by altering which immutable commit they point to in the backing store). And there is effectively an append-only audit trail of these alterations (which is what makes `jj undo`/`jj redo` simple).
Some comments here are confusing the issue by saying ‘commit’ when they mean ‘change’ in the jj sense.
Re the grandparent comment, `jj describe` provides a change description, analogous to `git commit --amend --edit` in git terms.
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.
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.)
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!
> 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.
I feel like a lot of this is an "elephant memory" problem, too. ("An elephant never forgets.") Git was built very quickly and its early CLI was intentionally rough. Git was originally built with the idea that it was going to be all "plumbing" and to leave the good UX decisions to whatever "porcelain" people wanted to use on top, with some even expecting that there might be multiple competing "official" "porcelain" CLIs. Eventually that debate got settled in the surprise way to some of the earlier decisions about git being plumbing-first in that eventually git picked up both the "plumbing" and the official "porcelain".
There's a lot of arguments that still seem to think of the git CLI before a lot of the porcelain projects started merging into git upstream. There's a lot of people that mostly only learned the plumbing tools and don't care for the porcelain projects. It certainly doesn't help that much of the best porcelain still isn't the default experience. You have to remember `git rebase -i` for the best porcelain rebase experience. You have to remember `git add -p` for the best porcelain add experience. (This article even indirectly hints at the silliness that the best interactive `git add` is `-p` for "pinteractive" because `-i` "interactive" was already taken by a weaker one.)
That said, a lot of the porcelain is there today to take advantage of. Git has improved significantly from its plumbing-first worst CLIs. `git checkout` finally got split into `git switch` and `git restore` and both of those are great. (And no longer marked "experimental", they are official daily-use approved porcelain now.)
That's also sort of the highlight of this post that a lot of the porcelain continues to improve. The UX of the git CLI isn't etched in stone. New, better commands are possible, and indeed are getting built by smart people, some of who even care about UX for themselves and their fellow developers. Git is no longer the rush project it once was. Git no longer sees itself as "plumbing-first" at the expense of the "porcelain".
It will just maybe take a while for more of the elephants to forget the past horror stories and befuddlement.
1. The way you delete things is just incomprehensibly inconsistent.
2. Naming of things is sometimes massively more confusing than it should be. Index? Why not "draft"? Ours/theirs presume some kind of ownership that doesn't exist, and they flip around depending on what command you're doing. To be fair a lot of the naming is decent.
3. The messages the CLI prints are unnecessarily obscure. They presume expertise without being friendly. For example look at the error you get from a submodule update where the commit can't be found. Does it say "Error: submodule points to <commit> but that commit was not found on the remote. Was it pushed?". No it does not. (I can't remember the exact message but I remember thinking how awful it was.)
> 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...
> people just don't take any time to learn git, then get on a soapbox about it.
That is true. However those same people that struggled for years with git are able to pick up jj and be very productive with no issue whatsoever, in a matter of days. So either:
1. jj is a lot more intuitive out of the box
2. or jj makes learning it fun, so more people do it
Whichever it may be, hopefully git can improve by learning from it and we all win. Don't you agree?
3. After years of refusing to learn git and making excuses for their hate, the goobers finally buckle down and read the manual for a tool that coincidentally does stuff a little different from git. They leap at the opportunity to further blame git for their difficulties rather than themselves.
If there is a way git can be made to appease these people without making it horrible, then we should try to do it. But I still think these people would be better served by buckling down for a few hours to learn git as it was designed, because it is designed very well.
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.
That is an absurd straw man. The point is, rebase workflow is ergonomic enough for the amount of splitting or rewording anyone realistically needs. Furthermore, knowing rebase is essential for things that these new tools can't do. It's best for people to use one familiar tool for everything IMO.
> rebase workflow is ergonomic enough for the amount of splitting or rewording anyone realistically needs
The point is this is perhaps true for you but most definitely not for others. there’s a Jevon’s paradox-like mechanic at play here which you can’t see if your axiom is ‘I don’t need this.’
jj is a "unofficial" Google project that one has to sign a Google CLA to contribute to. I don't think it would be a good idea to trust/transition to a system like that from git.
It's always the first step. The second step would be switching the license and only supporting the changed licensed version, then "donating" the unmaintained version to the community.
Has Google ever done this before though? I'm not much of a fan of Google either, but they tend to just abandon products outright rather than relicence them.
It's not documented, but unfortunately neither of these re-signs the commits even if GPG signing is configured. They are based on `git replay`, and that doesn't sign either (at least yet).
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.
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.
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.
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.
That doesn't automate the maintenance of the hooks, doesn't handle cross branch differences, opens you up to all kinds of security holes because now it'll just do whatever the hook points to which is likely to be in the repo and not in some special higher scrutiny flow...
All the push back to making this system good just ensures its as terrible as the nay-sayers fear.
The alternative is have hooks _forcibly_ run on people's machines, which is fantastic as an attack vector and CVE generator but probably not a good choice in other respects.
No there are a million miles in-between no support/Don't use it and arbitrary code execution.
Signed git plugins and manifest or a canonical way to define hooks in repo that most tools can interface with and allow the user to automatically set up but asks to do so or really so much more.
I don't know why people get fixated on this as if 99.999% of what git pulls down isn't code you expect to run and there are systems in place to protect that.
Why waste a round trip, build time, loss of flow and CI machine queue wait time when you can catch things early?
CI should also run all the checks but CI checks are not a replacement for local hooks. LFS and things like it can't be implemented as remote CI checks.
Why are we acting like a James Bond villain, slowly lowering the changes into the vat of sharks after we've left the room? I want the hooks. Can we talk about making that easy, assuming some people want them?
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?
You're talking out of both sides of your face here. It's dangerous and also it's super easy and you should do it first thing without having to think because it's so easy. You shouldn't run this code but also the build machine automatically runs it.
We already know we're definitely going to run some of these. We know we want to maintain changes to these hooks. Can we stop pretending like we're not doing that? We get it. Some of these will be untrusted so let's design a system to handle that instead of not designing a system and deciding to be just short of as unsafe as possible.
Automation an uniformity increases safety. Human intervention increases human error. Its just a matter of actually finding a good solution to know what is trusted but instead we get "just set it up manually because its safer."
> By running the linters and any other checks on CI instead.
Running linters on CI is an antipattern if there was ever one. That and configuring pipeline runs to fail for linting issues.
Sometimes some people just want to create their own problems. Configuring the editor solves most of the problems, and hooks add a failsafe. Once the code is committed, it should be immutable.
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.
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.
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?
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.
Git is already a build tool and LFS is a great example of something git should be able to do and is also an example of how bolted on these things feel because of pointless push back in talking about a real solution.
You don't need to bring up bad ideas as if it precludes the existence of good ideas. Let's talk about good ways to solve these problems and improve the tool.
I always considered hooks a nice to have feature for devs to already validate that their PRs will probably satisfy certain CI checks. If they don't install or run them for whatever reason, it's on them to do another iteration and update the code to make it mergeable if CI complains. So I usually considered it fine that they are only opt-in, since the merge will be gated by a CI outside of the dev's control anyway.
Adding configuration to the config makes things feel far less exotic. I think these changes certainly improve things, but there's still plenty of room to go further.
I think there should probably be a way to specify canonical git configuration for things like hooks and LFS and all of that. It would be nice if when you clone, git prompts you to trust the remote config or to ask you to accept each new change as they come or fully reject them.
Having to scrape through the readme of every repo and then run arbitrary scripts doesn't seem like the most secure solution. When there's a canonical flow gitlab GitHub and all the tooling can support it and have proper permissions around it.
It's really disappointing how much lack of empathy there is when talking about new git features. Forget empathy. There's outright disdain for discussing alternative workflows.
I wish that git would auto check for a `.githooks` directory in the repo root and prompt on first clone if the `core.hooksPath` should be changed for this repositry and when pulling any tracked file in hooksPath causes a warning (though this still leaves out the case that some hook just invokes a script in the repo outside the dir).
Many projects have used "hook managers" like Husky for this to install hooks to run based on repository-stored metadata.
These new config-based hooks are definitely a step down the road towards obsoleting the third-party hook managers. One of the things they are for is for managing scripts to support multiple hooks for the same event. The new config format supports multiple hooks for the same event natively. (Which also helps in stacking personal ones versus repository ones.)
The only thing missing is that the repository's .git/config isn't itself source controlled in that repository, so for now there would still be an "install step", but it's now a lot simpler of an "install step" with the install being "append .example-gitconfig into your .git/config" rather than "set X files to X different contents in .git/hooks/*" where X is the number of event hooks to be concerned about.
It does open the door further to if there should be a ".gitconfig" in the Repository working tree that can also contribute repository-wide shared config, what config it can or cannot contribute, and how you secure that as a reviewable opt-in (especially change notifications). But a smartly built secure UX there would be a massive improvement over, say, shell scripts in npm postinstall operations touching .git/hooks "for you" (which is how many of the current hook managers auto-install, as side effects in dependency installs).
(ETA: Though most "install scripts" now just use the very scriptable `git config` command and so just be `git config set --local hook.$name.$field $value` sequences, which is also a simpler improvement over previous ways to install and/or merge hooks files by hooks managers.)
While I understand the security concerns, too, wouldn't this be solved by including a `trust` command like in direnv and mise? (I.e. have the user review the hooks before executing them for the first time.)
The per-repo config is in `.git/config`, so that can still not be checked into the repo itself, unless I'm missing something?
So not very useful at all...
I get the security implications, but there could be a checked in `$REPO/.githooks`, and a prompt asking to allow running those hooks , with an approval marker being stored inside `.git/`.
This seems to be a first step in that direction, though. Merging repo suggestions into one per-repo `.git/config` is still a big improvement over N `.git/hooks/$EVENT` files. Plus the new config format is directly mergeable, whereas the old hooks files often weren't without extra work (they had to point to one and only one shell command, which might be an arbitrary binary rather than a mergeable shell script; hence why "hooks managers" are as much shell script managers as hooks file maintainers and often were generally mutually exclusive/do not cooperate).
Obviously it still leaves the door open if there should be a `.githooks` or `.gitconfig` file in the committed worktree that can suggest changes to `.git/config` with fewer manual steps, but this first effort in minimizing the number of manual steps and simplifying those manual steps to a simpler merge is still quite useful.
Which is also before pointing out that the `git config` command is already quite scriptable as a simple merge tool. You could in theory replace a "hooks manager" install script with just a sequence of `git config set --local hook.$name.*` lines. You still have to figure out how to get the user to run that script just like installing any other hooks manager, but that's an easy script now to write.
Though looks like `git history split` won't yet replace my typical workflow:
$ git rebase -i // with e on commit in question
$ git reset HEAD~
$ git add -p
As I can't edit the hunk.
`git history reword` will be handy once I wire up a script to pipe the log of recent commits through fzf for interactive selection (not sure if it's just me, but I prefer interactive selection over any other form of reference to a git hash).
And I bet I'll get some use out of `git rebase --trailer`.
Only a few days ago, I was just looking for some way to automatically check (and fail) if there are inactive hooks when I try to commit. I already use `advice.ignoredhook`, but it's easy to miss the warning if you commit through VSCode, and possibly through other IDEs.
With this, I can just write a simple script to perform that check, and add it to my global config
git history makes me think of git revise^1, which gives you a bunch of handy tools to changes your history, move commits around, remove some of them, cut them (which git history now does). I found it very handy in the past
git history is a genuinely welcome addition - rebase -i has always been a sledgehammer when sometimes you just need a scalpel, and it's nice to see git finally acknowledging that not every history edit needs to be a whole production
I hate to be the worry wart, but I am worried folks are going to avoid `git rebase -i` even more now. It is such an excellent excellent UI in my opinion: it shows you the history of what is clearly, and let's you modify it as you please!
If you have anything else branching/referencing a commit after the reword commit that isn't part of the branch you are rebasing you now have all those references still pointing to the old commit and need to go through every one of them to fix them.
Which is a reminder that maybe `--update-refs` should be the default for `git rebase -i`. It's great that it is now going to be the default for both `git replay` and `git history`, and I know why git is conservative in updating defaults, but at some point there's a benefit to updating the defaults. (I'd also argue that `-i` itself should have long been the default for `git rebase`. Also, while we are at it, probably `--autosquash` should be default.)
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.
I'd advise to do what you're doing, but to check the commands it runs and figuring out why it does these things. The first step is usally "what does git [command] do?" followed by `man git-[command]` and see what it does.
That way you're still "blazingly-fast with your SOTA-LLM!!!" while also understanding why :)
Nice to see some seemingly jujutsu inspired features getting into Git core.
https://git-scm.com/docs/git-history
https://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?
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.
> In jj, everything rewrites the history (...)
Surely that isn't true, otherwise it would be completely unusable for auditing.
it is true. some history is marked immutable by default; in git, everything is mutable by default and you have to add branch protection on the server side. (granted, you can change what is immutable in jj relatively easily, so you shouldn't ignore branch protection if you're using jj exclusively with a git repo, either.)
It's not true, in that sense. Commits in jj are basically the same as commits in git as far as mutability is concerned. But in jj you normally work with changes, rather than commits, and open changes are mutable (by altering which immutable commit they point to in the backing store). And there is effectively an append-only audit trail of these alterations (which is what makes `jj undo`/`jj redo` simple).
Some comments here are confusing the issue by saying ‘commit’ when they mean ‘change’ in the jj sense.
Re the grandparent comment, `jj describe` provides a change description, analogous to `git commit --amend --edit` in git terms.
By default, if you push to main/master, it marks those commits as immutable (you can still force change). You can configure this to other branches.
But ... is it really that different from git? You can always rewrite history in git, correct?
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.
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.
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!
> 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.
I feel like a lot of this is an "elephant memory" problem, too. ("An elephant never forgets.") Git was built very quickly and its early CLI was intentionally rough. Git was originally built with the idea that it was going to be all "plumbing" and to leave the good UX decisions to whatever "porcelain" people wanted to use on top, with some even expecting that there might be multiple competing "official" "porcelain" CLIs. Eventually that debate got settled in the surprise way to some of the earlier decisions about git being plumbing-first in that eventually git picked up both the "plumbing" and the official "porcelain".
There's a lot of arguments that still seem to think of the git CLI before a lot of the porcelain projects started merging into git upstream. There's a lot of people that mostly only learned the plumbing tools and don't care for the porcelain projects. It certainly doesn't help that much of the best porcelain still isn't the default experience. You have to remember `git rebase -i` for the best porcelain rebase experience. You have to remember `git add -p` for the best porcelain add experience. (This article even indirectly hints at the silliness that the best interactive `git add` is `-p` for "pinteractive" because `-i` "interactive" was already taken by a weaker one.)
That said, a lot of the porcelain is there today to take advantage of. Git has improved significantly from its plumbing-first worst CLIs. `git checkout` finally got split into `git switch` and `git restore` and both of those are great. (And no longer marked "experimental", they are official daily-use approved porcelain now.)
That's also sort of the highlight of this post that a lot of the porcelain continues to improve. The UX of the git CLI isn't etched in stone. New, better commands are possible, and indeed are getting built by smart people, some of who even care about UX for themselves and their fellow developers. Git is no longer the rush project it once was. Git no longer sees itself as "plumbing-first" at the expense of the "porcelain".
It will just maybe take a while for more of the elephants to forget the past horror stories and befuddlement.
I would say probably joint worst are:
1. The way you delete things is just incomprehensibly inconsistent.
2. Naming of things is sometimes massively more confusing than it should be. Index? Why not "draft"? Ours/theirs presume some kind of ownership that doesn't exist, and they flip around depending on what command you're doing. To be fair a lot of the naming is decent.
3. The messages the CLI prints are unnecessarily obscure. They presume expertise without being friendly. For example look at the error you get from a submodule update where the commit can't be found. Does it say "Error: submodule points to <commit> but that commit was not found on the remote. Was it pushed?". No it does not. (I can't remember the exact message but I remember thinking how awful it was.)
> 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...
> people just don't take any time to learn git, then get on a soapbox about it.
That is true. However those same people that struggled for years with git are able to pick up jj and be very productive with no issue whatsoever, in a matter of days. So either:
1. jj is a lot more intuitive out of the box
2. or jj makes learning it fun, so more people do it
Whichever it may be, hopefully git can improve by learning from it and we all win. Don't you agree?
I think you should consider a third option:
3. After years of refusing to learn git and making excuses for their hate, the goobers finally buckle down and read the manual for a tool that coincidentally does stuff a little different from git. They leap at the opportunity to further blame git for their difficulties rather than themselves.
If there is a way git can be made to appease these people without making it horrible, then we should try to do it. But I still think these people would be better served by buckling down for a few hours to learn git as it was designed, because it is designed very well.
Doesn't have to be a dig. One of the great things about having alternatives is that they can learn from each other.
and now git owes jj a couple ergonomic improvements. this is a net win for both.
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.
Ah, the Dropbox comment. You don’t even need git for that matter, you can switch between filesystem snapshots.
The point is, ergonomics matter. Rebase is not ergonomic for splitting commits.
That is an absurd straw man. The point is, rebase workflow is ergonomic enough for the amount of splitting or rewording anyone realistically needs. Furthermore, knowing rebase is essential for things that these new tools can't do. It's best for people to use one familiar tool for everything IMO.
> rebase workflow is ergonomic enough for the amount of splitting or rewording anyone realistically needs
The point is this is perhaps true for you but most definitely not for others. there’s a Jevon’s paradox-like mechanic at play here which you can’t see if your axiom is ‘I don’t need this.’
jj is a "unofficial" Google project that one has to sign a Google CLA to contribute to. I don't think it would be a good idea to trust/transition to a system like that from git.
what has one to do with the other...?
I'll consider avoiding jj because of this, personally.
It's always the first step. The second step would be switching the license and only supporting the changed licensed version, then "donating" the unmaintained version to the community.
Has Google ever done this before though? I'm not much of a fan of Google either, but they tend to just abandon products outright rather than relicence them.
Yeah it’s a direct inspiration.
It's not documented, but unfortunately neither of these re-signs the commits even if GPG signing is configured. They are based on `git replay`, and that doesn't sign either (at least yet).
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.
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.
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.
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.
That doesn't automate the maintenance of the hooks, doesn't handle cross branch differences, opens you up to all kinds of security holes because now it'll just do whatever the hook points to which is likely to be in the repo and not in some special higher scrutiny flow...
All the push back to making this system good just ensures its as terrible as the nay-sayers fear.
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.
This is very much not a serious solution. Look at the case of LFS.
LFS needs an install step and it needed to be brought into git itself to cut through all of the problems. Manually managing hooks is not sufficient.
No amount of "please don't fuck it up" in the readme is going to save you.
Even CI checks for what should and shouldn't look like an lfs stub is non-trivial. I don't think such a thing even exists today.
The alternative is have hooks _forcibly_ run on people's machines, which is fantastic as an attack vector and CVE generator but probably not a good choice in other respects.
No there are a million miles in-between no support/Don't use it and arbitrary code execution.
Signed git plugins and manifest or a canonical way to define hooks in repo that most tools can interface with and allow the user to automatically set up but asks to do so or really so much more.
I don't know why people get fixated on this as if 99.999% of what git pulls down isn't code you expect to run and there are systems in place to protect that.
You can issue installation instructions on linter failure in CI.
Why waste a round trip, build time, loss of flow and CI machine queue wait time when you can catch things early?
CI should also run all the checks but CI checks are not a replacement for local hooks. LFS and things like it can't be implemented as remote CI checks.
Why are we acting like a James Bond villain, slowly lowering the changes into the vat of sharks after we've left the room? I want the hooks. Can we talk about making that easy, assuming some people want them?
> 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?
You're talking out of both sides of your face here. It's dangerous and also it's super easy and you should do it first thing without having to think because it's so easy. You shouldn't run this code but also the build machine automatically runs it.
We already know we're definitely going to run some of these. We know we want to maintain changes to these hooks. Can we stop pretending like we're not doing that? We get it. Some of these will be untrusted so let's design a system to handle that instead of not designing a system and deciding to be just short of as unsafe as possible.
Automation an uniformity increases safety. Human intervention increases human error. Its just a matter of actually finding a good solution to know what is trusted but instead we get "just set it up manually because its safer."
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.
LFS hooks are not just a convenience, for example. CI, despite being a useful thing in its own right, is not a replacement.
Fair, I don't use LFS so I don't know how it works.
I was writing more in regards of hooks as "checks" for workflow/lints/etc.
> By running the linters and any other checks on CI instead.
Running linters on CI is an antipattern if there was ever one. That and configuring pipeline runs to fail for linting issues.
Sometimes some people just want to create their own problems. Configuring the editor solves most of the problems, and hooks add a failsafe. Once the code is committed, it should be immutable.
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.
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
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.
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 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.
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?
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.
Git is already a build tool and LFS is a great example of something git should be able to do and is also an example of how bolted on these things feel because of pointless push back in talking about a real solution.
You don't need to bring up bad ideas as if it precludes the existence of good ideas. Let's talk about good ways to solve these problems and improve the tool.
Yes that’s perfectly fine of course. But these days that’s not so common
I always considered hooks a nice to have feature for devs to already validate that their PRs will probably satisfy certain CI checks. If they don't install or run them for whatever reason, it's on them to do another iteration and update the code to make it mergeable if CI complains. So I usually considered it fine that they are only opt-in, since the merge will be gated by a CI outside of the dev's control anyway.
Adding configuration to the config makes things feel far less exotic. I think these changes certainly improve things, but there's still plenty of room to go further.
I think there should probably be a way to specify canonical git configuration for things like hooks and LFS and all of that. It would be nice if when you clone, git prompts you to trust the remote config or to ask you to accept each new change as they come or fully reject them.
Having to scrape through the readme of every repo and then run arbitrary scripts doesn't seem like the most secure solution. When there's a canonical flow gitlab GitHub and all the tooling can support it and have proper permissions around it.
It's really disappointing how much lack of empathy there is when talking about new git features. Forget empathy. There's outright disdain for discussing alternative workflows.
I wish that git would auto check for a `.githooks` directory in the repo root and prompt on first clone if the `core.hooksPath` should be changed for this repositry and when pulling any tracked file in hooksPath causes a warning (though this still leaves out the case that some hook just invokes a script in the repo outside the dir).
Many projects have used "hook managers" like Husky for this to install hooks to run based on repository-stored metadata.
These new config-based hooks are definitely a step down the road towards obsoleting the third-party hook managers. One of the things they are for is for managing scripts to support multiple hooks for the same event. The new config format supports multiple hooks for the same event natively. (Which also helps in stacking personal ones versus repository ones.)
The only thing missing is that the repository's .git/config isn't itself source controlled in that repository, so for now there would still be an "install step", but it's now a lot simpler of an "install step" with the install being "append .example-gitconfig into your .git/config" rather than "set X files to X different contents in .git/hooks/*" where X is the number of event hooks to be concerned about.
It does open the door further to if there should be a ".gitconfig" in the Repository working tree that can also contribute repository-wide shared config, what config it can or cannot contribute, and how you secure that as a reviewable opt-in (especially change notifications). But a smartly built secure UX there would be a massive improvement over, say, shell scripts in npm postinstall operations touching .git/hooks "for you" (which is how many of the current hook managers auto-install, as side effects in dependency installs).
(ETA: Though most "install scripts" now just use the very scriptable `git config` command and so just be `git config set --local hook.$name.$field $value` sequences, which is also a simpler improvement over previous ways to install and/or merge hooks files by hooks managers.)
> I understand there's a security reason for this
While I understand the security concerns, too, wouldn't this be solved by including a `trust` command like in direnv and mise? (I.e. have the user review the hooks before executing them for the first time.)
Config based hooks seem to miss the mark though?
The per-repo config is in `.git/config`, so that can still not be checked into the repo itself, unless I'm missing something?
So not very useful at all...
I get the security implications, but there could be a checked in `$REPO/.githooks`, and a prompt asking to allow running those hooks , with an approval marker being stored inside `.git/`.
This seems to be a first step in that direction, though. Merging repo suggestions into one per-repo `.git/config` is still a big improvement over N `.git/hooks/$EVENT` files. Plus the new config format is directly mergeable, whereas the old hooks files often weren't without extra work (they had to point to one and only one shell command, which might be an arbitrary binary rather than a mergeable shell script; hence why "hooks managers" are as much shell script managers as hooks file maintainers and often were generally mutually exclusive/do not cooperate).
Obviously it still leaves the door open if there should be a `.githooks` or `.gitconfig` file in the committed worktree that can suggest changes to `.git/config` with fewer manual steps, but this first effort in minimizing the number of manual steps and simplifying those manual steps to a simpler merge is still quite useful.
Which is also before pointing out that the `git config` command is already quite scriptable as a simple merge tool. You could in theory replace a "hooks manager" install script with just a sequence of `git config set --local hook.$name.*` lines. You still have to figure out how to get the user to run that script just like installing any other hooks manager, but that's an easy script now to write.
Excited for the new release!
Though looks like `git history split` won't yet replace my typical workflow:
As I can't edit the hunk.
`git history reword` will be handy once I wire up a script to pipe the log of recent commits through fzf for interactive selection (not sure if it's just me, but I prefer interactive selection over any other form of reference to a git hash).
And I bet I'll get some use out of `git rebase --trailer`.
The new additions to `git add -p` seem pretty neat. Staging changes with `-p` is seriously underrated!
Support for config based hooks is very nice.
Only a few days ago, I was just looking for some way to automatically check (and fail) if there are inactive hooks when I try to commit. I already use `advice.ignoredhook`, but it's easy to miss the warning if you commit through VSCode, and possibly through other IDEs.
With this, I can just write a simple script to perform that check, and add it to my global config
git history makes me think of git revise^1, which gives you a bunch of handy tools to changes your history, move commits around, remove some of them, cut them (which git history now does). I found it very handy in the past
1: https://git-revise.readthedocs.io/en/latest/man.html
git history is a genuinely welcome addition - rebase -i has always been a sledgehammer when sometimes you just need a scalpel, and it's nice to see git finally acknowledging that not every history edit needs to be a whole production
`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.
Why doesn't it do what you what?
I hate to be the worry wart, but I am worried folks are going to avoid `git rebase -i` even more now. It is such an excellent excellent UI in my opinion: it shows you the history of what is clearly, and let's you modify it as you please!
> Why doesn't it do what you what?
If you have anything else branching/referencing a commit after the reword commit that isn't part of the branch you are rebasing you now have all those references still pointing to the old commit and need to go through every one of them to fix them.
Which is a reminder that maybe `--update-refs` should be the default for `git rebase -i`. It's great that it is now going to be the default for both `git replay` and `git history`, and I know why git is conservative in updating defaults, but at some point there's a benefit to updating the defaults. (I'd also argue that `-i` itself should have long been the default for `git rebase`. Also, while we are at it, probably `--autosquash` should be default.)
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.
> ... rewrites any descendent branches to point at the updated history.
But what about local heads referred to only by a "soft" tag? Is their history rewritten, or is it left to refer to the old history?
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
I had to check and `jj describe` does. You get all the commit messages in a single file to edit, with headers separating them.
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.
I'd advise to do what you're doing, but to check the commands it runs and figuring out why it does these things. The first step is usally "what does git [command] do?" followed by `man git-[command]` and see what it does.
That way you're still "blazingly-fast with your SOTA-LLM!!!" while also understanding why :)
huh? I know git commands. it's just a dead skill with LLMs. SQL too.