Comment by ajoberstar
4 months ago
Nice to see some seemingly jujutsu inspired features getting into Git core.
git history reword ~= jj describe
git history split ~= jj split
https://git-scm.com/docs/git-history
4 months ago
Nice to see some seemingly jujutsu inspired features getting into Git core.
git history reword ~= jj describe
git history split ~= jj split
https://git-scm.com/docs/git-history
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).
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.
2 replies →
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.
3 replies →
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.
in jj the history has mutable and immutable commits.
Yeah it’s a direct inspiration.
If this is meant to be a dig, you should keep in mind how much jj owes to git.
Doesn't have to be a dig. One of the great things about having alternatives is that they can learn from each other.
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.
2 replies →
> 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...
2 replies →
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.
3 replies →