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.
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.
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'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.
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.)
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 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.
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.)
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.
> 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.’
I was on my 3rd Synology over the last 12 years or so. They were solid and something I didn't have to pay attention to.
But the drive lock-in tipped me over the edge when I needed to expand space. I'm getting burned out with all of these corporate products gradually taking away your control (Synology, Sonos, Harmony, etc.).
Even though it takes more time and attention, I ended up building my own NAS with ZFS on Debian using the old desktops I use for VMs. I did enjoy the learning experience, but I can't see it's that reasonable a use of time.
It doesn't seem like you're talking about the same thing the article is. Graham doesn't say "you must be a good writer to be a good thinker".
> This is only true of writing that's used to develop ideas, though. It doesn't apply when you have ideas in some other way and then write about them afterward — for example, if you build something, or conduct an experiment, and then write a paper about it. In such cases the ideas often live more in the work than the writing, so the writing can be bad even though the ideas are good.
Writers who have trouble expressing thoughts in a non-native language are not actually developing the idea in that language. That doesn't mean they are producing bad ideas, but it _might_ mean they won't produce good writing (in that non-native language).
I took the essay to be highlighting that if you use writing as a tool for thinking, clunky writing is likely to highlight places where your ideas themselves aren't clear or correct yet. The iterative process of refining the writing to "sound good" will help shape the ideas.
This seems to be a commonly expressed idea in other forms. For example, when thinking through ideas in code, the process of making the code more "beautiful" can also result in a clearer expression of more correct ideas.
> The problem stems from the fact that Unicode encodes characters rather than "glyphs," which are the visual representations of the characters. There are four basic traditions for East Asian character shapes: traditional Chinese, simplified Chinese, Japanese, and Korean. While the Han root character may be the same for CJK languages, the glyphs in common use for the same characters may not be. For example, the traditional Chinese glyph for "grass" uses four strokes for the "grass" radical [⺿], whereas the simplified Chinese, Japanese, and Korean glyphs [⺾] use three. But there is only one Unicode point for the grass character (U+8349) [草] regardless of writing system. Another example is the ideograph for "one," which is different in Chinese, Japanese, and Korean. Many people think that the three versions should be encoded differently.
That's not what happened. Downstream was building from source, that source just had malicious code in it.
One part was binary, the test file (pretty common), but checked into the repo. One part was in the build config/script, but was in the source tarball and not in the repo.
Git would make you merge or rebase, but yes there wouldn't be a conflict. They're saying Pijul would let you directly push without having to deal with the diverging histories.
Which tbh is a bad thing. Just because change a doesn't textually touch change b doesn't mean they don't interact.
Unless your VCS is handling CI for integrating changes on push, you really need to pull down the upstream changes first and test them combined with your code before blindly pushing.
> Which tbh is a bad thing. Just because change a doesn't textually touch change b doesn't mean they don't interact.
A good example for this is code which grabs several locks and different functions have to do that in the same order, or a deadlock will result. A lot of interaction, even if changes might happen in completely different lines.
And I think that's generally true for complex software. Of course it is great if the compiler can prove that there are no data race conditions, but there will always be abstract invariants which have to be met by the changed code. In very complex code, it is essential to be able to do bisecting, and I think that works only if you have a defined linear order of changes in your artefact. Looking at the graphs of changes can only help to understand why some breakage happened, it cannot prevent it.
I have clarified the comment above. A pull is needed before pushing. That pull does not need a merge or a rebase like git does because the order of commits A nd B does not matter (iff they are commutative). This gets a lot more useful when there are more than two patches to consider.
it already does.. you need an valid license to use DNF.. you can even get the RHEL install ISO but you will not get updates unless you active a license..
but some cloud providers offer vm with the license already in place, they pay the license in embed the cost in the vm price.. so the cloud provider that is bound by the eula..
https://www.jj-vcs.dev/latest/cli-reference/#jj-describe
https://www.jj-vcs.dev/latest/cli-reference/#jj-split