Lol. Orrr we could just do things sensibly in the first place.

I always chuckle when things like “sensible”, “user-friendly” or “sane” get thrown around as if they are anything more than that person’s opinion.

When are developers going to learn that they actually have to learn and familiarize themselves with preexisting systems, instead of endlessly reinventing them, and that there is no such thing as the perfect system?

Nothing is perfect, but some things are clearly better than others - hence why we’re nearly-all using git rather than "learning and familiarising ourselves" with CVS :)

Fair point, but it is not clear to me that Sapling is better than Git. I haven’t seen anything in its docs or in the comments here where I haven’t thought of a way to do it with Git.

I wonder what the cost benefit analysis would be: how many developers hours have been expended building Sapling so far, vs a list of things it can do that Git cannot.

And I guess it bears repeating that I’m interested in possibility and not aesthetics.

Given that they’re both open source and can be customised using turing-complete languages, the only limit to possibilities is how much effort you’re willing to put into customising them. Even CVS has the possibility of working as a distrubuted system if you wrap it up in enough layers of hacky shell scripts ;)

Having done quite a bit with both mercurial (which the sapling CLI is based on) and git, I find that the mercurial approach has a lot more sane defaults, is generally less effort for the same results, and has a lot of quality-of-life improvements — like git has the possibility of doing interactive commits with `git add -i`, but sapling's interactive-commit interface actually makes it usable.

The last thing I want to do is learn a new source control tool. For this to occur, it truly needs to be 10x better and not because someone isn't motivated enough to read the manual.

With how well git has worked for me, I suspect I'll use it for the rest of my career.

> where I haven’t thought of a way to do it with Git.

With git one can do "everything" true, doesn't mean that I want to teach everybody first what a DAG is and how one can manipulate that using git commands, but want to have something simpler. And yeah, git became a lot better over the years, but the plumbing still shines through in many places with inconsistencies.

Understanding a DAG becomes fundamental very quickly when trying to understand how distributed version control works. I would argue the opposite, that the internals are actually very reasonable and generic but it's the porcelain that has made some poor UX choices.

GitHub’s success was in part due to it making Git interface’s bareable. Imagine an UX so bad it generates a whole industry.

Lol wut. Github's success is in being a remote code repository.

So your claim is that GitHub would be equally successful if their website was just information about how to push to a git remote hosted by them?

SourceForge was pretty successful back in the day and they were pretty bland compared to GitHub.

GitHub's UX is so incredibly terrible. Pull Requests are horrible -- even mailing lists are better and that's impressive.

GitHub's UX is so bad it has indeed generated a whole industry of out-of-band review tools.

I don't think this is true. GitHub (the website) became very successful with virtually no feature overlap with the git CLI. I suppose you could say that GitHub pull requests and forks are a replacement for git's built-in email-based workflow, but that's not really what people complain about when they say git is hard to use (and it's not like the other DVCSes had obviously better solutions).