Jujutsu – A Git-compatible DVCS that is both simple and powerful

The git comparison docs have:

> Start working on a new change based on the branch -- jj co main

Did you consider the recent git nomenclature change to use "switch" for branch operations, and "co" for file operations? I actually can't tell from so deep in my "git Stockholm syndrome" whether that distinction is really hard on new users or not, but the fact that git expended the energy meant they thought it was meaningful

And, do you have plans on supporting signed commits, either via gpg or the newfound SSH key signing?

I'm super excited to try out the conflict resolution mechanism, because that's a major painpoint for my long-lived PR branches

We all know the dig here - Git is not simple.

Like many tools, Git has evolved significantly over the years. Git today was not like Git 10 years ago.

Also, like many replacements to existing tools and software, they always start out simple and beautiful. Then they grow in complexity to serve the domain. The reason Git is complicated - not "simple" - is mostly because version control _is_ complex.

I also don't agree that Git is hard to use. I feel it is an odd goal to try to make everything - even tools that experts use - simple to use, when they are fundamentally not simple. I feel like Git is sufficiently complex - no more than it needs to be and certainly not less.

Of course I cannot remember how exactly the "git rebase" command works and have to look it up every time, same as all those switches to the "simpler" commands.

I guess it all depends on what you need. Python looks really complicated too, if you start by browsing the function and class reference. But for someone starting to learn programming, it is apparently pretty easy (or so I've heard)

That said, building a version control system seems like a problem similar to a social network: the network affect causes an enormous amount of friction. i.e. most people don't want to use it until other people are using it. A vicious cycle.

The fact that it's compatible with git as a backend is really great though, and is probably the key to driving adoption. However I have several immediate thoughts that come to mind that cause me hesitancy. Answers in the README.md would be super helpful for marketing to me (and deep apology if it's there and I missed it):

1. How does it look to others working on the repo using just git? For example, "when the working copy is automatically committed," where does it go? is there a remote branch that someone could see if they `git fetch` while I'm working? I often put all sorts of things in the code that I don't want to have committed, ranging from harmless (a bunch of personal comments or `IO.puts()`), to very important (API keys and such that I'm testing with. I always move them to env vars before committing but for first-pass testing to prove the concept I "hardcode" them at first).[1]

2. Similar to "how does it look to others," what sort of burden does "all operations you perform in the repo are recorded, along with a snapshot of the repo state after the operation" put on the git backend? If I'm hacking on an ffmpeg script and I (temporarily) copy a 4GB mp4 file into the working directory so I can easily run `./mycode video.mp4`, does that whole thing get committed, potentially every time it changes? That could easily turn into a 40GB set of changes.[1]

3. Do you have to use the jj backend to get all the feature? For example, with a git backend could you get the two things mentioned above and also "Conflicts can be recorded in commits" as well?

A quick section in the README.md about which features require the jj backend instead of git would be super helpful, and if written well could answer all of the questions above.

To sum up my comment in a TL;DR: To really sell me on a project like this it has to work with git, and being able to quickly tell which features I can use with git, would make this substantially more interesting to me.

[1]: Related: https://xkcd.com/1172/