4 ms·

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

by blagie 3y ago

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.

cosmojg 3y ago
> The only argument I buy is: "2.6. Git provides a poor user experience," and the xkcd is not an exaggeration. Oh no. I'm the guy in the alt text. Should I be concerned?
thayne 3y ago
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.
- velcrovan 3y ago
  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.
- blagie 3y ago
  Redundant? 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.
johannes1234321 3y ago
> and providing ssh access to the directory Well, doing that securely and somewhat aclainf isn't easy and file access permissions are a pain. If you remember to update the index regularly serving .git via HTTP is easy for read-only access, but all else is quite a bit more involved.
- jwilk 3y ago
  "aclainf"?
- junon 3y ago
  I have no idea what this comment implies. File permissions are a Unix way of life. You'd always have security considerations even with Fossil.
- blagie 3y ago
  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.
xjapeonappy332 3y ago
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.
renegade-otter 3y ago
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.

by blagie 3y ago

cosmojg 3y ago

> The only argument I buy is: "2.6. Git provides a poor user experience," and the xkcd is not an exaggeration. Oh no. I'm the guy in the alt text. Should I be concerned?

thayne 3y ago

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.

velcrovan 3y ago
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.
blagie 3y ago
Redundant? 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.

johannes1234321 3y ago

> and providing ssh access to the directory Well, doing that securely and somewhat aclainf isn't easy and file access permissions are a pain. If you remember to update the index regularly serving .git via HTTP is easy for read-only access, but all else is quite a bit more involved.

jwilk 3y ago
"aclainf"?
junon 3y ago
I have no idea what this comment implies. File permissions are a Unix way of life. You'd always have security considerations even with Fossil.
blagie 3y ago
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.

xjapeonappy332 3y ago

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.

renegade-otter 3y ago

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.