That's an excellent description.

I still remember feeling like a badass using Git-SVN on my SVN-based team, and being the only guy who could actually correct bad merges and restore lost data without having to plead to our SVN admin.

And now I'm feeling like a badass using jj on my Git-based team :)

No LFS, submodules, hooks, or new tags means jj has some ways to go before it is a viable replacement for many organizations

https://jj-vcs.github.io/jj/latest/git-compatibility/

Having used git submodules, I see a lack of them as a feature. I honestly think that a script that checks out a specific commit from an external repository, combined with adding the path to the .gitignore is strictly better than submodules.

sure, but there are projects that use them already. If jj wants to replace git, it needs to work with people's existing projects without significant changes (ideally none at all)

Changing git hosts happens less frequently than changing clouds, which is infrequent. Changing VCS tools is even less frequent than either of those

git doesn't do everything that SVN does, so I don't think that's true.

The development world is much different and entrenched than it was when the move from svn -> git happened. Think of all the tooling, integrations, and automation we use these days. That was not happening 15+ years ago. I don't think svn as an analogy holds much water, tbh

Tooling, integrations, and automation (Including CI) were all things we used at my work when we switched from CVS to SVN almost 20 years ago.

Some people were, yes, but the scale of this has changed in those 20 years as well

How do you record the specific commit of the external repository, that was used in a specific commit of your repository?

LFS sorta works and submodules are just managed by git, and you can create tags with the git CLI just fine.

Hooks are a bigger change, though, for sure.

Sounds like I still need git for much of this, so jj and the things it does is and additional thing to manage. I've been told intermixing them is not a good idea

Sure. Use the tools you like!

At the same time, not everyone requires those features. All I mean to say is, the degree of support is varied out of the things mentioned, not just "no support for any of them."

It's still pre-1.0 software. We'll get there :)

The docs say "no" to support for all of those except tags, which is "partial" because jj can check it ou, but not create them, which hopefully is clear in my comment that "new tags" is still a "no"

I'm going to take the docs for what they say about support over an HN comment

You can trivially run `git tag` and create one, or in your forge and then pull it down. Creating one is not directly supported directly in jj's cli, but if you create a tag, it's in the repo just fine.

right, but then I'm using git, not jj, so why jj?

Why do people believe it's going to replace git if it won't do basic things we need. Why is it hard for jj to create a tag?

It’s not. It’s that there’s no inherent advantage to doing it natively when it works just fine via git. There’s more important things to do first, like many of the things on your list.

It’ll get there! Early days.

The advantage is in not requiring multiple tools to do the job when one already does it fine by itself.

jj claims there are these really bad problems with git, which is not my experience. Git is not on my list of pains in dev work