3 ms·

A postgres server is just a computer with 5432 open instead of 22. > If you keep it simple, it stays simple. Things that work well for one person in isolation

A postgres server is just a computer with 5432 open instead of 22. > If you keep it simple, it stays simple. Things that work well for one person in isolation don't work at scale or for teams. How do you handle authentication for your git server? What about backups? Manage disk space? Updates? That's before you get to the point of dealing with workflows and integrations, or "it's slow when 10 people clone at the same time"

marginalia_nu 5y ago
Every cloned git repository is a backup. That's like the entire point of git. It's decentralized version control. This is why the notion of a "git server" is a bit of an oxymoron. Most of the things you're struggling to solve are effectively preventing it from actually working as intended.
- RealStickman_ 5y ago
  You don't want to ask your users for their local backup Edit: To expand on my comment a bit. 1. You will have to check with every user when they last pulled their repos and/or made any local change and wanted to push it. 2. While your git is offline and you're figuring out which version is the most up to date your users can't do any work with git 3. You just lost all your issues, pull requests, wiki articles and more that isn't stored in git 4. Making backups is your job as a systems administrator and you just failed spectacularly
- maccard 5y ago
  > Every cloned git repository is a backup Is it? If I checksum the .git folder on my workstation and my co-workers workstation they're going to come back different. There's no guarantees that I haven't rebased main, or that I have all of the branches that were stored on the remote. If something catastrophic happens to our main remote, which one of our versions do we restore to? > It's decentralized version control. Just because git is decentralised, doesn't mean that it can only be used in a decentralised way. How many teams are pushing/pulling like a p2p network, and deploying to servers/clients from their workstations and verifying that the commit hash of their local repository matches what's deployed? A vanishingly small number of people. > Most of the things you're struggling to solve are effectively preventing it from actually working as intended If everyone is using it wrong, the tool is wrong. There are billion dollar companies out there that are based on a centralised git service, which proves that people can (and do) use tools in the way that makes sense, not necessarily as they were designed. Personally I'm glad I don't have to share patches over mailing lists with my coworkers, but you do you.
  - senko 5y ago
    I believe the core of your argument is that GitHub and GitLab provide more than just git DVCS. I don't think anyone argues with that. However, this core argument is obscured by a very emotional rejection of what the parent is saying - that you don't always need these additional things, and that you can (sometimes? often?) keep things simple. I think that's an interesting point to discuss. > If something catastrophic happens to our main remote, which one of our versions do we restore to? Dunno, talk it through? I hope you have a good enough relationship with your coworker that you can discuss your work with them. > Just because git is decentralised, doesn't mean that it can only be used in a decentralised way The OP not only did not say git can only be used in a decentralised way, they actually mentioned a git server - ie. a central point. > There are billion dollar companies out there that are based on a centralised git service, which proves that people can (and do) use tools in the way that makes sense, not necessarily as they were designed. Nobody argued otherwise. But, it is also true that there are billion-dollar companies out there that use an internal git service. How do I know that? Both GitHub and GitLab sell on-premises versions to those types of companies :) > Personally I'm glad I don't have to share patches over mailing lists with my coworkers, but you do you. Rationally, this argument is so off it can only be result of an emotional outburst. OP never mentioned sharing patches over mailing lists, and has in fact stated that it's easy to host git server. I understand and respect your argument and agree GitHub, GitLab and others provide valuable service. But gees, chill out, man. https://xkcd.com/386/ https://xkcd.com/386/
    - maccard 5y ago
      > You don't always need these additional things, and that you can (sometimes? often?) keep things simple. I think that's an interesting point to discuss. Agreed, however in my experience advocates for this kind of simplicity "don't need" these things, except they ad-hoc rely on piecemeal solutions. > Dunno, talk it through? I hope you have a good enough relationship with your coworker that you can discuss your work with them. This works on a team of 2. On a team of 10/20/50/100, pausing everything for everyone to figure out seems like a terrible idea. And teams of 2 quickly become teams of 10. > they actually mentioned a git server - ie. a central point. But they ignore all of the overhead of running a server, and fall back on it being decentralized as a solution to the "problems" of runnign a server. > Rationally, this argument is so off it can only be result of an emotional outburst. I'd really rather you didn't stoop to personal attacks on me, especially as I've done nothing of the sort. > OP never mentioned sharing patches over mailing lists, and has in fact stated that it's easy to host git server. OP said in his comment "Most of the things you're struggling to solve are effectively preventing it from actually working as intended. ". Given that git was designed for the linux kernel [0], a reasonable criticism of "working as intended" is criticising the workflow it was designed around. Running a git server doesn't give you _any_ way to collaborate or work with people, you need to build all of that tooling on top of it. The linux kernel uses patches distributed by email, despite hosting a git server. > But gees, chill out, man. https://xkcd.com/386/ https://xkcd.com/386/ I've downvoted you specifically for this part of your comment, it's an unnecessary personal attack. [0] https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git https://git-scm.com/book/en/v2/Getting-Started-A-Short-Histo...
- Hackbraten 5y ago
  But what would your disaster recovery process look like?
  - marginalia_nu 5y ago
    $ git clone ...
    - Hackbraten 5y ago
      Allow me to rephrase. You’re responsible for 1000 Git repositories used by developers all over your department. Some (or even all) of those have just been wiped in a ransomware attack. Whom are you going to tell to `git clone` what from where?
      - marginalia_nu 5y ago
        From any machine who has checked out the code? That's sort of the point of git. Any cloned version of a repository is a "git server" in itself.
        0ldskool 5y ago
        So the solution is to individually track down each cloned git repo on developers workstations. Then have each developer open up SSH access for others to clone using SSH or run an HTTP server? Also keep in mind not all repo's may have been cloned, up-to-date, etc... DVCS is designed to propagate code to many people and allow them to easily modify and share with others who also have a copy. If people don't have a copy they can get a copy of a copy (which at some point may have been modified). In a large company you need a Single source of centralized truth. You cannot build a company on the concept of "it works on my dev workstation" or the worse suggestion here "all the company's IP source code is on only on my dev workstation".
hedora 5y ago
You need to have port 22 open to manage the postgres server. Postgres also (probably) has a worse track record with remotely exploitable bugs than openssh. Answering your other questions: Authentication: ssh keys Backups: the same way you back up the rest of the machine (s3 snapshots of ebs?), or run a second server at a different site with a cron job that runs "git fetch --all" or whatever. Manage disk space: It's not the 90's anymore. How are you running a 1TB machine out of disk space with a git repo? Updates: Enable unattended updates in whatever distro you are running. If you are running a separate backup server, pick more than one upstream operating system (redhat, Debian, arch, BSD), so a botched update won't break both. Git hooks work fine for workflows and integrations. Is it really slow when 10 people clone at once? How is that even possible on modern hardware with 100's GB of RAM and dozens of cores?

marginalia_nu 5y ago

Every cloned git repository is a backup. That's like the entire point of git. It's decentralized version control. This is why the notion of a "git server" is a bit of an oxymoron. Most of the things you're struggling to solve are effectively preventing it from actually working as intended.

RealStickman_ 5y ago
You don't want to ask your users for their local backup Edit: To expand on my comment a bit. 1. You will have to check with every user when they last pulled their repos and/or made any local change and wanted to push it. 2. While your git is offline and you're figuring out which version is the most up to date your users can't do any work with git 3. You just lost all your issues, pull requests, wiki articles and more that isn't stored in git 4. Making backups is your job as a systems administrator and you just failed spectacularly
maccard 5y ago
> Every cloned git repository is a backup Is it? If I checksum the .git folder on my workstation and my co-workers workstation they're going to come back different. There's no guarantees that I haven't rebased main, or that I have all of the branches that were stored on the remote. If something catastrophic happens to our main remote, which one of our versions do we restore to? > It's decentralized version control. Just because git is decentralised, doesn't mean that it can only be used in a decentralised way. How many teams are pushing/pulling like a p2p network, and deploying to servers/clients from their workstations and verifying that the commit hash of their local repository matches what's deployed? A vanishingly small number of people. > Most of the things you're struggling to solve are effectively preventing it from actually working as intended If everyone is using it wrong, the tool is wrong. There are billion dollar companies out there that are based on a centralised git service, which proves that people can (and do) use tools in the way that makes sense, not necessarily as they were designed. Personally I'm glad I don't have to share patches over mailing lists with my coworkers, but you do you.
- senko 5y ago
  I believe the core of your argument is that GitHub and GitLab provide more than just git DVCS. I don't think anyone argues with that. However, this core argument is obscured by a very emotional rejection of what the parent is saying - that you don't always need these additional things, and that you can (sometimes? often?) keep things simple. I think that's an interesting point to discuss. > If something catastrophic happens to our main remote, which one of our versions do we restore to? Dunno, talk it through? I hope you have a good enough relationship with your coworker that you can discuss your work with them. > Just because git is decentralised, doesn't mean that it can only be used in a decentralised way The OP not only did not say git can only be used in a decentralised way, they actually mentioned a git server - ie. a central point. > There are billion dollar companies out there that are based on a centralised git service, which proves that people can (and do) use tools in the way that makes sense, not necessarily as they were designed. Nobody argued otherwise. But, it is also true that there are billion-dollar companies out there that use an internal git service. How do I know that? Both GitHub and GitLab sell on-premises versions to those types of companies :) > Personally I'm glad I don't have to share patches over mailing lists with my coworkers, but you do you. Rationally, this argument is so off it can only be result of an emotional outburst. OP never mentioned sharing patches over mailing lists, and has in fact stated that it's easy to host git server. I understand and respect your argument and agree GitHub, GitLab and others provide valuable service. But gees, chill out, man. https://xkcd.com/386/ https://xkcd.com/386/
  - maccard 5y ago
    > You don't always need these additional things, and that you can (sometimes? often?) keep things simple. I think that's an interesting point to discuss. Agreed, however in my experience advocates for this kind of simplicity "don't need" these things, except they ad-hoc rely on piecemeal solutions. > Dunno, talk it through? I hope you have a good enough relationship with your coworker that you can discuss your work with them. This works on a team of 2. On a team of 10/20/50/100, pausing everything for everyone to figure out seems like a terrible idea. And teams of 2 quickly become teams of 10. > they actually mentioned a git server - ie. a central point. But they ignore all of the overhead of running a server, and fall back on it being decentralized as a solution to the "problems" of runnign a server. > Rationally, this argument is so off it can only be result of an emotional outburst. I'd really rather you didn't stoop to personal attacks on me, especially as I've done nothing of the sort. > OP never mentioned sharing patches over mailing lists, and has in fact stated that it's easy to host git server. OP said in his comment "Most of the things you're struggling to solve are effectively preventing it from actually working as intended. ". Given that git was designed for the linux kernel [0], a reasonable criticism of "working as intended" is criticising the workflow it was designed around. Running a git server doesn't give you _any_ way to collaborate or work with people, you need to build all of that tooling on top of it. The linux kernel uses patches distributed by email, despite hosting a git server. > But gees, chill out, man. https://xkcd.com/386/ https://xkcd.com/386/ I've downvoted you specifically for this part of your comment, it's an unnecessary personal attack. [0] https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git https://git-scm.com/book/en/v2/Getting-Started-A-Short-Histo...
Hackbraten 5y ago
But what would your disaster recovery process look like?
- marginalia_nu 5y ago
  $ git clone ...
  - Hackbraten 5y ago
    Allow me to rephrase. You’re responsible for 1000 Git repositories used by developers all over your department. Some (or even all) of those have just been wiped in a ransomware attack. Whom are you going to tell to `git clone` what from where?
    - marginalia_nu 5y ago
      From any machine who has checked out the code? That's sort of the point of git. Any cloned version of a repository is a "git server" in itself.
      - 0ldskool 5y ago
        So the solution is to individually track down each cloned git repo on developers workstations. Then have each developer open up SSH access for others to clone using SSH or run an HTTP server? Also keep in mind not all repo's may have been cloned, up-to-date, etc... DVCS is designed to propagate code to many people and allow them to easily modify and share with others who also have a copy. If people don't have a copy they can get a copy of a copy (which at some point may have been modified). In a large company you need a Single source of centralized truth. You cannot build a company on the concept of "it works on my dev workstation" or the worse suggestion here "all the company's IP source code is on only on my dev workstation".

hedora 5y ago

You need to have port 22 open to manage the postgres server. Postgres also (probably) has a worse track record with remotely exploitable bugs than openssh. Answering your other questions: Authentication: ssh keys Backups: the same way you back up the rest of the machine (s3 snapshots of ebs?), or run a second server at a different site with a cron job that runs "git fetch --all" or whatever. Manage disk space: It's not the 90's anymore. How are you running a 1TB machine out of disk space with a git repo? Updates: Enable unattended updates in whatever distro you are running. If you are running a separate backup server, pick more than one upstream operating system (redhat, Debian, arch, BSD), so a botched update won't break both. Git hooks work fine for workflows and integrations. Is it really slow when 10 people clone at once? How is that even possible on modern hardware with 100's GB of RAM and dozens of cores?