git history reword ~= jj describe
git history split ~= jj split
Surely that isn't true, otherwise it would be completely unusable for auditing.
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.
But ... is it really that different from git? You can always rewrite history in git, correct?
‘jj describe’ lets you add a message to a commit as it’s not there by default.
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!
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.
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.)
This command is implemented by just one single (but prolific) contributor. His own idea.
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...
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.
The point is, ergonomics matter. Rebase is not ergonomic for splitting commits.
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.’