Most of these arguments are nonsense. "Standing up a git server is non-trivial." It's literally just "git init" and providing ssh access to the directory. Most of the other ones seem to suggest the author never learned git.
git has a beautiful data model and a horrible user-space to poke at it. Writing a new user-space makes sense. This seems to poorly re-invent the data model, by virtue of not bothering to understand git.
The only argument I buy is: "2.6. Git provides a poor user experience," and the xkcd is not an exaggeration.
No. It's not. Set up git-shell instead of bash, and you're done. It's literally a one-liner.
There are similar one-liners for most other use-cases.
As a footnote, most environments I'm in, this is a non-issue since devs have ssh access to a common server somewhere. Once you get to the org size where this matters, it doesn't matter since you need Infrastructure with a capital I regardless.
Says the person who clearly has never been the sysadmin for said web server.
Dealing with SSH on a significantly multi-user system is anything but trivial. In more ways than one, this exact problem more than anything else is what spurred the invention of what we now call containers, and it still is not a perfect solution.
Right, and a lot of tools out there already provide a less horrible Git experience by taking care of all the user-hostile command-line arguments (SmartGit, etc).
The only problem with Git is that it is not user-friendly - and that is the Porcelain, the nice API version.
It is non-trivial to stand up a redundent, highly-available, and scalable git server. And if you throw in "with a good web interface", even moreso. But I doubt that is trivial to do with fossil either.
What do you mean by redundant, highly available? Under what circumstances are those necessary? Whatever it is, seems completely orthogonal to version control software. Anyways, I can serve a fossil repo with a great web UI and a few 9s of reliability on an existing web server with literally a 2-line CGI script.
I think at some point, you missed the point of a DVCS.
Scalable?
When do you run into issues with git server scalability that an 80486 couldn't handle?
Highly-available?
At this point, just pay for !@#$ github. But it's a heck of a lot easier to do this in a DVCS than in fossil. Options:
- Set up two servers. Add a hook to push from one to the other whenever a change happens. If the main server goes down, swap to the backup, and bring up a new one as a backup.
- Store the git repo on a redundant, highly-available, scalable file system, and run a few git servers on the shared file system. Back in my day, we'd use AFS for this.
The nice thing about the data model is these solutions /work/. The basic git data model* won't be corrupted if multiple systems are writing to it more-or-less simultaneously. Absolute worst case is the tree splits and you've got a detached head somewhere, but no data is lost.
* I can't speak for some of the more advanced stuff (packing, compression, etc.), since I don't fully understand it; but it's possible to disable all of that.
git has a beautiful data model and a horrible user-space to poke at it. Writing a new user-space makes sense. This seems to poorly re-invent the data model, by virtue of not bothering to understand git.
The only argument I buy is: "2.6. Git provides a poor user experience," and the xkcd is not an exaggeration.