Will this have any chance if Jujutsu/jj doesn't get more traction? The effort to learn a new VCS is less than for a programming language, but many developers have not learned git in depth, and Mercurial and others have not gained a lot of traction.
Not really. I remember my early years with git and the favt was that I never needed more than clone, add, commit, pull and push. While I’ve done some mistakes that got ne to learn more, especially with creating branches and undoing. I’ve never needed a lot, even when I started using GUI which exposed more concepts.
Why? Because I have no understanding of version management and how it’s useful in a dev workflow/release process. I was just using it for checking in work.
Since then, I’ve read the “Pro Git” book, learned how devs and teams handle versioning and devel a good understanding of how git can help me in my coding process and general software development. And it’s very good at what it does.
Git is quite powerful, but the cli is a train wreck of complexity and inconsistency. Learning the options to one git command means you’ve learned the options to exactly one git command. No other git command is required to use the same terminology. Personally, I was stuck in “git basics land” (all the basic commands you list) until I adopted Magit in Emacs. IMO, the Magit team deserves a medal for making git usable at an advanced level.
I don’t have an opinion about jj yet, but no one can hold up git as a pinnacle of great source control. Yes, it’s powerful, but it’s a UI train wreck.
You forgot the “because it's actually kind of terrible from a UX standpoint”. My stance is against that. I haven’t learned git in depth because I never knew any other workflow than code and check in the changes. There’s not a lot of guides on how version control can help in the software development process.
It wasn’t until I got involved into OSS that I learned more which in turns give me the motivation to use and learn about git in depth. I’m also using magit (after a tour in various GUI) but for me it is to git what vi is to ex. Direct interaction instead of a command prompt.
I'm not sure I understand how "I use a specific text editor with a specialized interface into git that's superior" is a counterargument to the first-party tool having horrible UX. That seems basically the exact same as what I was saying about jj, except via emacs instead of a CLI. Either way, we've opted out of the actual experience of the tool in favor of using an alternative tool that operates on the version control.
It requires the same mental model as git.
The repository is a store, you check out the previously saved instance of a file, a group of files, or a subtree. In that regards, switching branches and restoring files is actually the same thing. A commit stores whole files and branches are pointers to commits (which update themeselves).
Maybe you can explain how is it leaky based on your understanding of version control?
At the team level, it’s guided by the release process, configuration management, which version is canonical. At the programmer level, it’s usually guided by how to switch between task, how easy to explore an idea and save the resulting experiment, how to reset the code to a know state and how to replay a previous changes on top of new changes.
So you discern what you want to do (which is independent of the tool), the learn how to use git to do them. If you start from git, you’re going to be confused, just like someone opening autocad with no knowledge of engineering drawing.
EDIT: GitHub had probably the first UX where I actually liked what I got, compared to various earlier git based ones, or the horrible CVS and SVN ones where clicking on a file name definitely didn't do what you expected.
I barely remember Bitbucket from the mercurial era but I do recall that while it was better than some, it was still worse than GitHub, whose "here's default branch's HEAD, plus auto-opened and formatted README" was really a game changer
I also have used plenty of SCM systems since mid-90's.
TBH learning git in depth was a hindrance for me learning jj - for my first few weeks I kept instinctively looking for complex solutions to simple problems and being confused, when the answer was always "use the tools you already know"
As a concrete example - git has one set of commands for managing commits, a different set of commands for managing the index, a third set of commands for managing stashes, a fourth set of commands for managing the working directory, and a fifth set of commands for managing conflicts -- in jj all of those things are a single concept with a single set of commands, equally (if not more) powerful, but also simpler
They have less to walk away from then.