101–110 of 114 posts
Earlier quoted context omitted.
definitely the best git repo for small teams! better than gitolite and manual hosting, lighter than gitlab, the best for me.
Do you do code review in your teams? That's the main reason that I am using Gitlab over Gogs/Gitea for my team.
Earlier quoted context omitted.
On the contrary, there's a ton of maintenance, and the hosting providers like GitHub and Microsoft pay teams of people to deal with the infrastructure. (I've worked on both.) This involves not just the physical infrastructure like the servers, though of course there's that, but also maintaining the bits on disk. Your repository will get duplicated across multiple disks on multiple machines, perhaps in different avail…
GitHub etc. need "a ton of maintenance" because of the "fancy tools", which are an unusually complex and sophisticated constantly evolving web application with many users. A private source repository is far less demanding: it's almost never upgraded, and for system administrators it's just another server to keep running and another file system to back up.
GitHub is distributing your Git repository across multiple servers in multiple racks in real time for reliability and availability and is the world's largest Git repository hosting provider. Some nice conference talks discuss this, like from Git Merge: https://www.youtube.com/watch?v=f7ecUqHxD7o and GitHub Universe: https://www.youtube.com/watch?v=DY0yNRNkYb0
Visual Studio Team Services is hosting your Git repository across Azure, and is hosting the world's largest Git repositories. https://arstechnica.co.uk/information-technology/2017/02/mic...
I have my own Git server as well, and I agree that its maintenance isn't very demanding. But I'm not putting production bits on it. My open source repositories go to GitHub and my private repositories go to VSTS - they're providing a level of service that I simply can't match by myself.
Earlier quoted context omitted.
It's especially sad because git is distributed and every time there's a GitHub outage I hear online some teams are blocked for the day. But everyone has the whole repo. You're not screwed like if your SVN or Perforce server goes down. Anyone could become the new "remote to push to / pull from" until the outage is resolved, or you could set up one of these bare repos somewhere pretty quick. When the outage is resolved…
This is what happens when people cargo-cult git because it's what the cool kids are doing, instead of actually making an informed choice.
Fixed that for you.
Security question. Can `git-shell` restrict users to their remote home directory? Or if you give me a git shell, can I still do things like `git clone me@example.com:/home/you/secret-sauce` ? This is only an issue if you're sharing the box and/or remote repositories with other people. For shared remote repositories I've been using the following setup: 1. Create a bare, shared repository at `/var/git/foo`. Configure u…
For multi-user use probably best solutions are scripts/systems that automate this whole thing like gitosis and gitolite. You get multiple users logging in as same system user which are authenticated by their SSH key and administration of the thing is mostly performed by commiting into special git repository.
Earlier quoted context omitted.
This is what happens when people cargo-cult git because it's what the cool kids are doing, instead of actually making an informed choice.
S/git/GitHub/ Fixed that for you.
Earlier quoted context omitted.
S/git/GitHub/ Fixed that for you.
Well, that too, but the issue here (thinking that a central repo being offline means you can't use your decentralized version control system) shows that they don't understand git in any form.
If you’re using Google Cloud, you can already use Google Cloud Source Repositories. https://cloud.google.com/source-repositories/ It supports git and the Beta release of Cloud Source Repositories provides free hosting of up to 1GB of storage.
For those who aren't aware, Git is actually a fully decentralised system. It doesn't require a central server as such - though most teams use one, as it's a convenient setup for most projects. Even if you are hosting on github/bitbucket/et. al. though, that repository is just one of many equals. You can push and pull from multiple peers as long as you have access set up appropriately. I recommend the chapter on distr…
Earlier quoted context omitted.
On the contrary, there's a ton of maintenance, and the hosting providers like GitHub and Microsoft pay teams of people to deal with the infrastructure. (I've worked on both.) This involves not just the physical infrastructure like the servers, though of course there's that, but also maintaining the bits on disk. Your repository will get duplicated across multiple disks on multiple machines, perhaps in different avail…
GitHub etc. need "a ton of maintenance" because of the "fancy tools", which are an unusually complex and sophisticated constantly evolving web application with many users. A private source repository is far less demanding: it's almost never upgraded, and for system administrators it's just another server to keep running and another file system to back up.
"Just another server to backup" is, indeed, not a big deal. It's strictly more work than not having another server to backup, however, and when it fails, it fails hard--in the sense of, "Hey, I just blew Saturday fixing my personal git server" or "Hey, I just lost data because I realized my backup cron was broken."
Running your own server is a bug, not a feature. The fact is, it's a very _minor_ bug because running your own is so damn easy. But it's still a bug. (The fact that you can run your own server, in the contrary, is a feature.)