Jujutsu for everyone

One showstopper for me is that Jujutsu doesn’t support .gitattributes (https://jj-vcs.github.io/jj/latest/git-compatibility/).

or LFS, hooks, submodules, shallow clones

In every one of these threads I learn some new axis of git that JJ doesn't support, so I really do wonder if JJ should have squatted upon a different DVCS given how much it wants to do things the JJ way leading to folks with git experience being sad

nah, git was absolutely the right thing to squat on - its ubiquitous, so making it seamlessly powerful and easy to use makes for easy adoption. If it was built on pijul or whatever, I'd never have given it a try.

to the extent that niche things might not be supported (yet), so be it. It suits the needs of the vast majority of people. Moreover, if you need those things, I BET you can just do it via git and then carry on working in jj, since jj sits on top of git

.gitattributes has only caused me trouble, so I wouldn't really miss it. IMO it's a footgun.

So it doesn't have most of the worst features git ever invented. Got it.

Ehh these are mostly edge case features that are very important to some, but not relevant to most. I've been using Jujutsu full time with dozens of repos and the only one that's come close to mattering is submodules (which are easy to work around with a colocated repo + `git submodule update`).

CRLF autoconversions especially shouldn't have been supported, imho. Git on Windows's default setup still converts LF to CRLF to this day, even though every program on Windows has understood LF for a number of years.

I can understand the criticism to submodules but the rest of your comment feels like unwarranted snark.

Hooks, submodules, and LFS all have huge followings of haters. I think just a week ago there was a big post on HN about how awful LFS is.

Adoption probability without git squatting would be virtually zero.

I'm all for functionality, but git should never have been a smorgasbord of random bolt-on special cases. If you have to break the basic core functionality to make a feature work, it's not a good feature.

It's the only way to ensure proper cross-platform EOL handling when you can't rely on users configuring their local Git appropriately.

Of course, it also requires users to use the official Git client, so that .gitattributes are actually observed. But that's more likely to be the case in practice.

I never said jj was awesome. I've never used it. I'm already adept at git, enough to have opinions on its advanced features, and the knowledge to avoid them, so I'm not sure if I'd gain all that much from jj.

LFS is pretty crap, but the problem it tries to solve is real: version control should be able to control all the sources of the application, not just the text-based sources. Even if it can't meaningfully "diff" between them.

The correct way to do cross-platform EOL handling is to use LF for all files on all platforms, and enforce that via hooks or CI. Every program on Windows, including the humble Notepad, understands LF these days.

Git for Windows configures core.autocrlf to true by default. This is a terrible idea, imho. "input" is a bit more justifiable.

If you have to deploy or test with CRLF files, you can’t force LF for all files. This isn’t about editors, but about files to be deployed on customer systems, and/or to be used in tests, where the interfacing software has other requirements. You also have to use .gitattributes to reliably define which files to treat as text files in the first place. And you’d have to define your hooks and CI checks to be consistent with that. Note that Git always converts CRLF to LF upon check-in for defined-to-be-text files, even on Unix.

I agree that the default on Windows is wrong. “Input” isn’t much better.

Tests that require CRLF should transform files as appropriate within a temporary directory. That way the costs of non-standard line endings are borne by the places that need it, as opposed to by all tooling in perpetuity.