Jujutsu and Radicle

No they are not. In theory they could be good, but the actual implementation falls down in ... let me count the ways:

1. Transitive dependencies. I sure do love that my company's submodule-based repo has 12 copies of one of our dependencies.

2. Checkouts don't work any more. You can't simply `git switch `, especially if that other branch has a different set of submodules. And good fucking luck if one branch has a submodule and another branch has a not-submodule in the same location.

3. They don't work with worktrees. In theory... maybe. In practice, the documentation says not to try and in my experience it is right!

4. The submodule URLs are now baked into the git repo. This means you can't mirror the repo anymore easily. I've even had cases where I couldn't even clone the repo because the authors had used `ssh://` URLs which required permissions I didn't have. It's insane that the authentication method gets baked into the repo. I have no idea why they implemented it like this.

5. The tooling experience is just way worse. Want to see a diff of everything you've changed? Well you can't. If you've changed anything in a submodule you just get a hash difference, or at best a list of commits (which is better but it's not even the default!).

Before you instinctively reach for the "well obviously it must work like that" part of your brain, take a moment to think if it should work like this. I can think of several ways to do it better (beyond just making the implementation less buggy).

- While I'm working on something I can do `jj desc` and start writing the commit message. Every edit is automatically being added to this change.

- My work tree is dirty and I quickly want to switch to a clean slate. In Git: (1) either do `git stash` where I'm definitely is going to forget about it or (2) do `git commit -a -m wip && git switch -c some-random-branch-name`. In jj: `jj new @-`. That's it! If I run `jj log` then my previous change shows up. No need to come up with arbitrary names. It's so refreshing to move changes around.

- I'm working on a stack of changes and sometimes need to make edits to different parts. In Git (1): Each change is its own branch and I need to switch around and do a bunch of rebases to keep them in sync. In Git (2): I have one branch with multiple commits. I make changes towards the final state and then do `git rebase -i` to move them upwards to where they belong. Biggest downside: I'm not actually testing the changes at the point where they end up and I'm not guaranteed it makes sense. In jj: I do `jj new ` to make changes further up in the stack. Once I'm happy with it I do `jj squash` and every dependent change is automatically rebased on top.

- And finally: I can solve merge conflicts when I want to! If any rebasing leads to a merge conflict I don't have to deal with it right away.

For example: let's say you have a few feature branches in flight at the same time, and you want to make a change to one of them to address some PR feedback. In your git workflow, that presumably means something like `git stash; git checkout feature-name; vim-and-actually-make-the-change; git add -up; git commit; git push; git checkout whatever-you-were-doing-before; git stash pop`, ± a `--amend` depending on your PR philosophy. A common workflow in jj is to instead sit on top of a merge commit with all the feature branches at once, and handle this like `vim-and-actually-make-the-change; jj squash -i --into feature-name; jj git push`. You can do something like the latter in git too, of course, it just tends to get hairy relatively quickly with rebases and merge conflicts.

Except, dependencies are rarely read-only.