10 ms·

We centralized a decentralized version control system.

ReverseCold 9y ago
We centralized a decentralized communication system too. (eMail) Decentralization just doesn't work too well in practice for whatever reason. Everyone is behind a NAT/firewall, everyone has low computing power, its hard to regulate, etc. This all leads to a centralized solution being easier. I think the current best thing we have is centralized but open source and encrypted, which gets an "okay"/10 from me.
- masklinn 9y ago
  > Decentralization just doesn't work too well in practice for whatever reason. Because it's inconvenient. Centralisation is convenient, it gives a single discovery and synchronisation point. Decentralisation makes discovery much more difficult, and requires adding separate synchronisation mechanisms. It generates friction and cognitive overhead. Even more so for "side-services". Sure your VCS is nominally decentralised[0], but what about bug reports? Contributions? Notes & docs? There were distributed bug trackers efforts back in the early 10s but… they didn't really work IME, they were not convenient or practical. [0] though even without a single giant point of failure, most project would still have a single canonical master copy, a really mesh/distributed contribution system is very rare (Linux's tree of integrators/forks is probably the closest?) and none of the current VCS makes mesh/point-to-point collaborations really convenient
shawabawa3 9y ago
$2 billion to the first person to draft a decentralised git coin WhitePaper
- coding123 9y ago
  I think you just did.
  - drdaeman 9y ago
    No. We need a proper whitepaper explaining how to make GitHub decentralized with blockchain tokenization using distributed smart-contracts. ;) (Did I forget any important buzzword?)
    - unit91 9y ago
      You nailed it for the devs but you gotta' say it to people who would pay for it too. Decentralized GitHub would synergistically leverage our existing cloud infrastructure to provide unprecedented collaboration that is open, robust, efficient, and focused.
    - karlmcguire 9y ago
      Just don't host it on Github Pages.
      - deleted 9y ago
        [deleted]
    - zbentley 9y ago
      Did I forget any important buzzword? Nah, but you could always add some Serverless and Lambada to make it more Agile.
      - JohnStudio 9y ago
        "crypto" baiting is like the funniest trend ever in the Stock Market lately. Kodak is riding that pony home ... (noting I live in Buffalo, just down the road from Kodak's home turf in Rochester and I'm a pretty avid photographer - http://www.instagram.com/crispyfotos/ http://www.instagram.com/crispyfotos/).
      - mcguire 9y ago
        "Did I forget any important buzzword?" BigDataDeepLearning.
- jradd 9y ago
  SIA coin is a similar concept. They even have video hosting/streaming on their development roadmap. Decentralized storage, filesystem and social media seem to be the most valuable use–case for blockchains aside from the inherent value of cryptocurrency. https://sia.tech/whitepaper.pdf https://sia.tech/whitepaper.pdf
- mhluongo 9y ago
  Gitcoin already exists :) https://gitcoin.co/ https://gitcoin.co/
- thinkmassive 9y ago
  It's funny that there's already a Gitcoin project, however they do NOT have a token: https://gitcoin.co/ https://gitcoin.co/ The goal of the project is to incentivize FOSS development, similar to Bountysource, except without requiring participants to trust a central party. It's pretty cool!
chrisseaton 9y ago
You can still work with your colleagues by pushing and pulling your own repos without involving GitHub. I think centralised CI is the real problem. I don't have the compute power in my home to run our full test suite, so I can't push with confidence without my CI cluster.
- drdaeman 9y ago
  GitLab CI is really sweet, because you deploy your own runners (workers) whereever you want. Downside is, the control is not a standalone CI app but a part of GitLab (or I'm unaware about something). Drone is very promising but last time I've checked the documentation had some holes in it. The website is "coming soon" and IIRC it's like this for quite a long while. I'm unaware about any CIs that are usable with local repos. Would be neat to just run a local command and it would spawn a worker somewhere (local or through a remote coordinator) and run the tests on whatever I have in the working tree, just like it happens with centralized repo+CI combos. It's too frequent I find myself doing `git commit -m 'Fix that stupid typo in previous commit'`.
  - sytse 9y ago
    We're working on a 'CI only' mode so you can easily use GitLab CI without the rest of GitLab. This is already possible but now it requires some configuration. For your local use case GitLab Runner has a local mode exec, although that is currently being reworked https://gitlab.com/gitlab-org/gitlab-runner/issues/2797#note_51070788 https://gitlab.com/gitlab-org/gitlab-runner/issues/2797#note...
- TAForObvReasons 9y ago
  Issues and other GH infrastructure is arguably a bigger problem. That metadata is locked within the Github silo with no easy way to export it elsewhere.
  - dom96 9y ago
    This is indeed the crux of the problem. I've been thinking about this a lot (and I wouldn't be surprised if it exists already), we need a decentralised method of storing issues and other things inside our git repos.
vuldin 9y ago
The issue is that the features we use along with git, many of which github provides, are not decentralized. The true but tired argument that git will continue to work when github goes down totally ignores this issue. Yes, git still works. But we don't just rely on the features git provides.
- chrisseaton 9y ago
  So this isn't really anything to do with Git then is it? So why joke we centralised Git when really we centralised a bunch of other things that are not really anything to do with Git?
  - hashkb 9y ago
    Because we also centralized git.
  - rplnt 9y ago
    It's also the issue with git, if it goes down and you don't update your local clones ~daily (or as other mentioned don't have system in place that would allow you to update somewhat locally).
naiveai 9y ago
That's kind of missing the point, everyone's git local clones are still there, I can still work on the code. Git's decentralisation is meant to make sure work doesn't stop altogether when the remote is down.
nickysielicki 9y ago
The concept of an "upstream" is inherently centralized. The point of git is that everyone can keep working right now and can push later without things getting very messy.
runeks 9y ago
So you’re saying that if I put up my own Git server (for a fee), it’s likely to have better uptime statistics than GitHub? I can’t push changes to the decentralized Git protocol, only to a (centralized) server instance.
- dorfsmay 9y ago
  Setting up your own instance of a bit server is free. If you want issues, CI etc... Then you need a local version of github which you will pay for.
  - jupblb 9y ago
    Personally, I prefer something more lightweight and for some time I've been using gogs - https://github.com/gogits/gogs https://github.com/gogits/gogs (so far so good)
    - majewsky 9y ago
      Is gogs maintained anymore? Everyone I know switched to the community fork, gitea.
      - jupblb 9y ago
        Wow, I haven't peeked at the commit history for some time. Thanks for the info!
  - lykr0n 9y ago
    Or GitLab. That's free and easy to self host.
    - apple4ever 9y ago
      Bingo. People think its hard to self host. Its not. They have an omnipackage that you install. You run updates. You enable the automatic backups. Problem solved!
peterwwillis 9y ago
Welcome to the modern tech world. While you're waiting for the site to come back up, let me tell you all about my new startup, SquareWheel(TM). edit: Oh jesus christ, there's a fucking tech company called Square Wheel. Kill me now.
- neosavvy 9y ago
  Tell me more - sounds like a productive thing to work on given all productivity is gone for the immediate foreseeable future.
golergka 9y ago
Am I the only one who has project's mirror on Gitlab for exactly this purpose?
- kuon 9y ago
  I have it the other way around. I use gitlab with github as backup.
- mmahmad 9y ago
  I'm curious as to how you manage the mirror. Do you perform all operations twice (e.g. if you push to Github, do you manually push to Gitlab)? Edit: Nvm, found out Gitlab has the mirroring feature (https://docs.gitlab.com/ee/workflow/repository_mirroring.html https://docs.gitlab.com/ee/workflow/repository_mirroring.htm...). Pretty cool!
dehef 9y ago
No way to build my npm dependencies. So the day github would really crash/lost some files, the package decency system thing is dead. That is a very exciting scenario... as exiting as if google would forget to renew google.com and would have no legal right to get it back.
Cthulhu_ 9y ago
The VCS is still decentralized (you can share code with your neighbour or across the world), it's the administration (tickets, PRs, etc) that aren't. I think it'd be fairly straightforward for github or a competitor to store those things in git as plain markdown files, either alongside the main source code, or (as it does with GH Pages) in a separate branch (that has nothing in common with the master branch but it's still in the same repo). Similar (maybe) is ADR (http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions http://thinkrelevance.com/blog/2011/11/15/documenting-archit...), storing architectural decisions into numbered files in git. See also: https://github.com/npryce/adr-tools https://github.com/npryce/adr-tools
- Conan_Kudo 9y ago
  Fedora's Pagure[1] implements those administrative bits as Git repos. Issues are stored in a Git repository along with the git repo for the code. [1]: https://pagure.io/pagure https://pagure.io/pagure
da_chicken 9y ago
The major feature of git is that it's distributed, not that it's decentralized. Git's got two big features over SVN: 1. Automatic, private, per-user branching. Git's even nice enough to keep the private branches out of the main repository, and lets you pretend to be the authoritative repository without creating a branch if you really want to. This is what clone/push/pull actually does, and it's what a distributed VCS really brings to the table. It lets every dev pretend to be the project manager when they're writing their own code. 2. A much improved merging model. The graph model of git is just much better than the linear model of SVN. The second one is what people thought they wanted when they started using git. The first one is what they didn't know they wanted before they started using git. Git gets around the problem of "Well, if we do #1, how do we know which repository is authoritative then?" by saying, "We're not solving that problem. This is an exercise for the users that's easily solved by file permissions." So by refusing to solve that (rather hard) problem, the VCS becomes internally decentralized. That doesn't mean you can't or shouldn't centrally manage your repositories or have an authoritative repository. It's just that git itself doesn't care about knowing which repository is authoritative.

We centralized a decentralized communication system too. (eMail) Decentralization just doesn't work too well in practice for whatever reason. Everyone is behind a NAT/firewall, everyone has low computing power, its hard to regulate, etc. This all leads to a centralized solution being easier. I think the current best thing we have is centralized but open source and encrypted, which gets an "okay"/10 from me.

masklinn 9y ago
> Decentralization just doesn't work too well in practice for whatever reason. Because it's inconvenient. Centralisation is convenient, it gives a single discovery and synchronisation point. Decentralisation makes discovery much more difficult, and requires adding separate synchronisation mechanisms. It generates friction and cognitive overhead. Even more so for "side-services". Sure your VCS is nominally decentralised[0], but what about bug reports? Contributions? Notes & docs? There were distributed bug trackers efforts back in the early 10s but… they didn't really work IME, they were not convenient or practical. [0] though even without a single giant point of failure, most project would still have a single canonical master copy, a really mesh/distributed contribution system is very rare (Linux's tree of integrators/forks is probably the closest?) and none of the current VCS makes mesh/point-to-point collaborations really convenient

shawabawa3 9y ago

$2 billion to the first person to draft a decentralised git coin WhitePaper

coding123 9y ago
I think you just did.
- drdaeman 9y ago
  No. We need a proper whitepaper explaining how to make GitHub decentralized with blockchain tokenization using distributed smart-contracts. ;) (Did I forget any important buzzword?)
  - unit91 9y ago
    You nailed it for the devs but you gotta' say it to people who would pay for it too. Decentralized GitHub would synergistically leverage our existing cloud infrastructure to provide unprecedented collaboration that is open, robust, efficient, and focused.
  - karlmcguire 9y ago
    Just don't host it on Github Pages.
    - deleted 9y ago
      [deleted]
  - zbentley 9y ago
    Did I forget any important buzzword? Nah, but you could always add some Serverless and Lambada to make it more Agile.
    - JohnStudio 9y ago
      "crypto" baiting is like the funniest trend ever in the Stock Market lately. Kodak is riding that pony home ... (noting I live in Buffalo, just down the road from Kodak's home turf in Rochester and I'm a pretty avid photographer - http://www.instagram.com/crispyfotos/ http://www.instagram.com/crispyfotos/).
    - mcguire 9y ago
      "Did I forget any important buzzword?" BigDataDeepLearning.
jradd 9y ago
SIA coin is a similar concept. They even have video hosting/streaming on their development roadmap. Decentralized storage, filesystem and social media seem to be the most valuable use–case for blockchains aside from the inherent value of cryptocurrency. https://sia.tech/whitepaper.pdf https://sia.tech/whitepaper.pdf
mhluongo 9y ago
Gitcoin already exists :) https://gitcoin.co/ https://gitcoin.co/
thinkmassive 9y ago
It's funny that there's already a Gitcoin project, however they do NOT have a token: https://gitcoin.co/ https://gitcoin.co/ The goal of the project is to incentivize FOSS development, similar to Bountysource, except without requiring participants to trust a central party. It's pretty cool!

chrisseaton 9y ago

You can still work with your colleagues by pushing and pulling your own repos without involving GitHub. I think centralised CI is the real problem. I don't have the compute power in my home to run our full test suite, so I can't push with confidence without my CI cluster.

drdaeman 9y ago
GitLab CI is really sweet, because you deploy your own runners (workers) whereever you want. Downside is, the control is not a standalone CI app but a part of GitLab (or I'm unaware about something). Drone is very promising but last time I've checked the documentation had some holes in it. The website is "coming soon" and IIRC it's like this for quite a long while. I'm unaware about any CIs that are usable with local repos. Would be neat to just run a local command and it would spawn a worker somewhere (local or through a remote coordinator) and run the tests on whatever I have in the working tree, just like it happens with centralized repo+CI combos. It's too frequent I find myself doing `git commit -m 'Fix that stupid typo in previous commit'`.
- sytse 9y ago
  We're working on a 'CI only' mode so you can easily use GitLab CI without the rest of GitLab. This is already possible but now it requires some configuration. For your local use case GitLab Runner has a local mode exec, although that is currently being reworked https://gitlab.com/gitlab-org/gitlab-runner/issues/2797#note_51070788 https://gitlab.com/gitlab-org/gitlab-runner/issues/2797#note...
TAForObvReasons 9y ago
Issues and other GH infrastructure is arguably a bigger problem. That metadata is locked within the Github silo with no easy way to export it elsewhere.
- dom96 9y ago
  This is indeed the crux of the problem. I've been thinking about this a lot (and I wouldn't be surprised if it exists already), we need a decentralised method of storing issues and other things inside our git repos.

vuldin 9y ago

The issue is that the features we use along with git, many of which github provides, are not decentralized. The true but tired argument that git will continue to work when github goes down totally ignores this issue. Yes, git still works. But we don't just rely on the features git provides.

chrisseaton 9y ago
So this isn't really anything to do with Git then is it? So why joke we centralised Git when really we centralised a bunch of other things that are not really anything to do with Git?
- hashkb 9y ago
  Because we also centralized git.
- rplnt 9y ago
  It's also the issue with git, if it goes down and you don't update your local clones ~daily (or as other mentioned don't have system in place that would allow you to update somewhat locally).

naiveai 9y ago

That's kind of missing the point, everyone's git local clones are still there, I can still work on the code. Git's decentralisation is meant to make sure work doesn't stop altogether when the remote is down.

nickysielicki 9y ago

The concept of an "upstream" is inherently centralized. The point of git is that everyone can keep working right now and can push later without things getting very messy.

runeks 9y ago

So you’re saying that if I put up my own Git server (for a fee), it’s likely to have better uptime statistics than GitHub? I can’t push changes to the decentralized Git protocol, only to a (centralized) server instance.

dorfsmay 9y ago
Setting up your own instance of a bit server is free. If you want issues, CI etc... Then you need a local version of github which you will pay for.
- jupblb 9y ago
  Personally, I prefer something more lightweight and for some time I've been using gogs - https://github.com/gogits/gogs https://github.com/gogits/gogs (so far so good)
  - majewsky 9y ago
    Is gogs maintained anymore? Everyone I know switched to the community fork, gitea.
    - jupblb 9y ago
      Wow, I haven't peeked at the commit history for some time. Thanks for the info!
- lykr0n 9y ago
  Or GitLab. That's free and easy to self host.
  - apple4ever 9y ago
    Bingo. People think its hard to self host. Its not. They have an omnipackage that you install. You run updates. You enable the automatic backups. Problem solved!

peterwwillis 9y ago

Welcome to the modern tech world. While you're waiting for the site to come back up, let me tell you all about my new startup, SquareWheel(TM). edit: Oh jesus christ, there's a fucking tech company called Square Wheel. Kill me now.

neosavvy 9y ago
Tell me more - sounds like a productive thing to work on given all productivity is gone for the immediate foreseeable future.

golergka 9y ago

Am I the only one who has project's mirror on Gitlab for exactly this purpose?

kuon 9y ago
I have it the other way around. I use gitlab with github as backup.
mmahmad 9y ago
I'm curious as to how you manage the mirror. Do you perform all operations twice (e.g. if you push to Github, do you manually push to Gitlab)? Edit: Nvm, found out Gitlab has the mirroring feature (https://docs.gitlab.com/ee/workflow/repository_mirroring.html https://docs.gitlab.com/ee/workflow/repository_mirroring.htm...). Pretty cool!

dehef 9y ago

No way to build my npm dependencies. So the day github would really crash/lost some files, the package decency system thing is dead. That is a very exciting scenario... as exiting as if google would forget to renew google.com and would have no legal right to get it back.

Cthulhu_ 9y ago

The VCS is still decentralized (you can share code with your neighbour or across the world), it's the administration (tickets, PRs, etc) that aren't. I think it'd be fairly straightforward for github or a competitor to store those things in git as plain markdown files, either alongside the main source code, or (as it does with GH Pages) in a separate branch (that has nothing in common with the master branch but it's still in the same repo). Similar (maybe) is ADR (http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions http://thinkrelevance.com/blog/2011/11/15/documenting-archit...), storing architectural decisions into numbered files in git. See also: https://github.com/npryce/adr-tools https://github.com/npryce/adr-tools

Conan_Kudo 9y ago
Fedora's Pagure[1] implements those administrative bits as Git repos. Issues are stored in a Git repository along with the git repo for the code. [1]: https://pagure.io/pagure https://pagure.io/pagure

da_chicken 9y ago

The major feature of git is that it's distributed, not that it's decentralized. Git's got two big features over SVN: 1. Automatic, private, per-user branching. Git's even nice enough to keep the private branches out of the main repository, and lets you pretend to be the authoritative repository without creating a branch if you really want to. This is what clone/push/pull actually does, and it's what a distributed VCS really brings to the table. It lets every dev pretend to be the project manager when they're writing their own code. 2. A much improved merging model. The graph model of git is just much better than the linear model of SVN. The second one is what people thought they wanted when they started using git. The first one is what they didn't know they wanted before they started using git. Git gets around the problem of "Well, if we do #1, how do we know which repository is authoritative then?" by saying, "We're not solving that problem. This is an exercise for the users that's easily solved by file permissions." So by refusing to solve that (rather hard) problem, the VCS becomes internally decentralized. That doesn't mean you can't or shouldn't centrally manage your repositories or have an authoritative repository. It's just that git itself doesn't care about knowing which repository is authoritative.