I always struggle with "lowering the barrier of entry" and it's not a "I did it they need too do it" it's more of a "Usually high barriers mean it's complex, and learning how to understand complex things is important."
If this was some new novel way to version that wasn't just pretty git, I'd be a lil more excited.
Now the guy was pretty technical (part of his job was AS development), but he was not a developer.
Darcs's and Git's fundamentals are not that different[0], but Darcs's CLI actually makes sense in and of itself independent from the implementation details, and when it diverges from the older standard (e.g. SVN) it's so that commands make more sense, not less. Meanwhile Git has taken pretty much the opposite tack.
Git's porcelain is a giant steaming roasted turd sandwich, no other DVCS has such a complex, hostile and nonsensical CLI that people tell you you're supposed to learn it from the storage model up and then it'll make sense.
Don't try to shift the buck to VCS/DVCS concepts, while they are complex Git's CLI goes a great way towards making them nonsensical to beginners and non-beginners alike. I routinely used three different DVCS before I had to take the plunge into Git, and it was still a fucking pain in the ass. And that's a problem at every level of resolutions, just compare the hot mess that is gitrevisions(7) to mercurial's (more powerful, more flexible, more readable and more regular) revsets. It's not like revsets are a genius's flash of inspiration either, "hey I'm trying to manipulate sets of revisions, how about I manipulate them as sets?" We're not talking turing award worthy discovery here.
[0] well they kinda are, but by and large the fundamental differences are irrelevant to basic day-to-day use.
NO IT IS NOT. <smack to back of head> That kind of thinking is broken.
Most people who have been around computers on Windows long enough eventually adopt it. They start creating zip files of directories and they put date codes on them. You laugh, but it works.
As such, it's really easy for me to explain Mercurial to them. I simply explain it that Mercurial holds those zip files with some extra information and a pretty GUI. It takes me 30 minutes, max, and they get it.
They have one branch. They occasionally share things with other people. And, very occasionally, they have to merge something--which generally gets resolved by taking this file or that file--but rarely actually merging content.
Things only start to go bad when you start adding concepts that require the user to keep state of the repository in their head. If the end user has to think about the DAG, yeah, THAT'S complicated. And that's broken.
I've now been using git and hg for so long that I know both. I now know enough about git that I have been able to unwedge my teams without just copying the repo (cue xkcd link: https://xkcd.com/1597/). I don't need to spend hours of Googling anymore, I just need quick reminders of "Oh, yeah, that stupid flag."
And, you know what, I have never, ever been in a situation where I thought "Gee, I really wish I was in git rather than Mercurial." The converse, however, happens at least once a week.
Perhaps one day my teams or my repos will be complicated enough that the light dawns. The fact that the *BSD guys still operate using CVS and Subversion makes me skeptical.
We should be celebrating better UIs over important tools, not saying "I made great effort to learn it, therefore learning it with less effort is inferior". No. If it does everything Git does, but more easily, it is strictly superior.
Meanwhile, unlike Git, I understood most of Gitless's commands before the tutorial started explaining them. Opposite experience I got with Git tutorials where I kept questioning why it would be done a certain, unintuitive way. This is definitely an improvement.
I don't think git's command line needs to be changed, though.
>If it does everything Git does, but more easily, it is strictly superior.
In the abstract I agree, but if an junior dev goes "oh, I just use gitless because it's easier" and DOESN'T understand git, it's a problem. That's my point.
I'm always suspicious of arguments like this, because they have a Luddite quality to them. Isn't sending email versus handwritten postal mail "cheating the effort" of communication?
git is a lot of effort to learn because its command line is inconsistent and it is frequently unclear what it has done, why and how to recover from it. It is worth asking if this is really necessary.
If a system has a high percentage of beginners pressing the wrong button and losing time and effort as a result, maybe someone should move the buttons?
Eclipse has stuff like workspaces with multiple projects and others have simply projects. What to do with these workspaces?
Same goes with Git. Simple VCS have central repositories and a working copy. Git has multiple repositories and every one of them can have a working copy. Other VCS don't have a stage, you simply commit your changes directly into your repository.
It's not only that these tools have different commands and stuff like Mercurial or Subversion has easier commands etc. but they really have different concepts that need to be considered while working with these tools on a daily basis.
But you don't have to internalize them on your first week or month working with them. When you got your project in the System it's mostly save and if you don't have complex workflows you can still reap the benefits of VCS with Git without knowing everything.