It's not needlessly complex. The workflow it was created to support is inordinately complex, and the target market for that is highly technical, so its complexity was not the issue. Kernel developers needed to communicate to other kernel developers in a decentralized manner, and needed to work on top of each other. How do you work on a project where there are 15,000 people writing code? Git was created for this purpose.
It's as complex as it needs to be to support the workflows it was designed to be. A dumber tool would be easy to create, but then it would not be able to support more complex workflows like linux kernel development. So it's not needlessly complex, though it is more complex than it needs to be for simple use cases.
For those needing a less complicated frontend, there's a large number of them to make it easier to interact with git. For people that aren't full-time software developers, I don't recommend using git directly. However for those that are, it's worth taking the time to understand the underlying concepts so git becomes something you understand because once you do, it's quite elegant for what it does. I'm not going to gatekeep being a software developer on whether or not you know git, but if figuring out for yourself how such a fundamental system works doesn't give you a release of dopamine, this might not be your kind of thing. Which is totally fine. There are tons of things that are and aren't my thing.
After learning Jujutsu, I realized this is really wrong. The underlying data structures and operations are great, and they serve their purposes really well (such as supporting 10k+ people collaborating like you mentioned). They are what makes git great. The git command line interface is a needlessly complex abstraction on top of them that tries to encourage certain behaviors, but does a really bad job at it.
There are 3 different ways I could get to the store, I could walk or drive or bicycle. There are also 3 different paths I can take. I could go down road A, sidestreet B, or alleyway C. I know you'd rather one big button to press that just says "do it" on it, but in order to perform complex actions on complex objects, there are going to be multiple ways to accomplish the same thing.
But what if one of the ways to the store is dangerous once in a while but usually safe and always just as fast as the other 2 ways to the store.. Laziness has nothing to with the posters question. There is nothing wrong with Git , I just don't agree with the comparison.
But if the dangerous route takes only 15 minutes, and the safe ones take an hour, why shouldn't I, being fully aware of the risks, have the option to take it when I want to?
I'll have to dig into https://github.com/martinvonz/jj hadn't heard of it before. Either way, there's an underlying data structure with operations to be performed on, the interface to it is shit, and learning the underlying data structure makes it all make sense.
I see that (in principle at least) it can be a simple UI for an existing git repo but then it gets kind of complicated again discussing how that works.
I can tell you how to do a bunch of things with Jujutsu without looking it up: how to rebase a tree of branches given a common ancestor, how to do a 3+ way merge, how to split the changes in a commit into multiple commits, how to duplicate a branch, how to find all of the commits that haven't made it into the default branch...
I can't tell you how to do a single one of these things in git without looking it up. My years of experience with git is around a decade I think. My experience with Jujutsu adds up to about 3 months.
Sure, there are things that I would still have to look up how to do with Jujutsu; I don't know all of its features. I think the operations I know how to do with Jujutsu off the top of my head are strictly a superset of the operations I know how to do with git though.
There's a common(?) use case for git/jujutsu that I can't find a simple answer to:
I clone a repo. I make some changes to my copy. But then I want to keep my copy up to date with the original repo by stirring in all the updates that have been made lately to the original repo.
Seems like it oughta be simple, but git makes it mysterious. Will jujutsu make this possible using only simple, sensible CLI commands ? And conflicts will be nicely stored away for near-term cleanup ?
jj fetch # get the most recent changes from the remote
jj rebase -b @ -d branch@remote # rebase the branch of the current working commit onto the newly fetched commits.
Note that the way to do this with git is almost identical, but maybe not as obvious. In git I think this can be done with a single command though: git pull --rebase.
If this is not the state you want your repo to be in and I misunderstood, I'm still pretty confident I could get a repo in the state you want using Jujutsu quite easily :)
Edit: though also the git way to do this would kind of force you to deal with cleaning up conflicts immediately, whereas with Jujutsu you can put off conflicts indefinitely.
"Needlessly" can be in the eye of the beholder, but given that Linus basically put it together to solve the problem he was trying to solve without consulting a UX team or building a product for the ages, I would be willing to place my probability bar pretty high on the design tilting towards "One person's best idea right now" over "Best design theoretically possible."
That having been said, the team is really good at engines so the software is quite good at doing what it's supposed to do.
It's as complex as it needs to be to support the workflows it was designed to be. A dumber tool would be easy to create, but then it would not be able to support more complex workflows like linux kernel development. So it's not needlessly complex, though it is more complex than it needs to be for simple use cases.
For those needing a less complicated frontend, there's a large number of them to make it easier to interact with git. For people that aren't full-time software developers, I don't recommend using git directly. However for those that are, it's worth taking the time to understand the underlying concepts so git becomes something you understand because once you do, it's quite elegant for what it does. I'm not going to gatekeep being a software developer on whether or not you know git, but if figuring out for yourself how such a fundamental system works doesn't give you a release of dopamine, this might not be your kind of thing. Which is totally fine. There are tons of things that are and aren't my thing.
I recommend https://learngitbranching.js.org for learning how to navigate around git.
but of course, https://xkcd.com/1597/ applies as well.