4 ms·

I've said it before and I'll say it again... It makes zero sense to centralize something that was meant to be decentralized. We need issues, pull requests, com

I've said it before and I'll say it again... It makes zero sense to centralize something that was meant to be decentralized. We need issues, pull requests, comments, milestones, wiki, etc... all to be decentralized. No reason this stuff cannot be modeled using existing Git objects. GitHub, GitLab and BitBucket are extremely similar. Almost 100% overlap, you could use the lowest common denominator between the 3 and you'd still have 95% of the features.

exikyut 9y ago
1. Businesses need a "halp everything is on fire" button that costs them $1000 a second but will fix EVERY issue, (virtually) guaranteed by SLA. Ultimately that is what these orgs provide; the hosting is kind of almost secondary to that. 2. Actually building real-world implementations of "Issues, pull requests, comments, milestones, wiki, etc..." requires top-tier engineer[ing] time and energy to build and maintain. The current Git-on-steroids-aaS approach provides a very successful way to fund that undeniable cost.
hobofan 9y ago
> No reason this stuff cannot be modeled using existing Git objects. That's the easy part. The hard part is discovery and keeping stuff like teams and moderation when you decentralize it. Advancements in Blockchain-tech, IPFS and similar will make this viable soonish-ly, but I think we are not quite there yet from a technological standpoint.
- sillysaurus3 9y ago
  How is blockchain related to this?
  - rightos 9y ago
    Didn't you get the memo? If you stamp enough buzzwords on everything, it magically works, regardless of their relevance to the application.
    - hobofan 9y ago
      I see you got the memo that being dismissive of everything that contains buzzwords is still popular ;) Both IPFS and blockchain are definitely applicable to decentralizing applications. E.g. DSound[0], a distributed version of Soundcloud is built with IPFS + a blockchain(not necessarily a fan of STEEM though). There could just as well be something analogous for Github, Bitbucket, etc.. [0]: https://steemit.com/music/@prc/introducing-dsound-a-decentralized-sound-platform-using-steem-and-ipfs https://steemit.com/music/@prc/introducing-dsound-a-decentra...
  - hobofan 9y ago
    Blockchains allow for a distributed, mutable permissioned system that are required(?) for features like "Who is allowed to push to this named repository?". You can also leave stuff like that out, but then you will end up with a system where everyone can only push to their own forks leaving us with a very splintered distributed system. To compensate we would need a much better system for distributed content discovery than anything I've seen so far.
    - icebraining 9y ago
      You don't need a Blockchain for that. You just store the public keys of the allowed users on the repository itself. Giving readable names to repositories is a possible use case, although I'd just use DNS.
      - hobofan 9y ago
        Yeah, I guess you are right, a blockchain is probably not an absolute requirement for that. I think though, that decentralized maintenance of open source project would be a logical next step, and a blockchain-based system could certainly be useful there. This could help prevent a lot of stale/abandoned projects from dying where the only maintainers of a project leave it to rot and there is no one left to review PRs coming from the community.
        icebraining 9y ago
        How would the blockchain help there?
    - deleted 9y ago
      [deleted]
  - deleted 9y ago
    [deleted]
  - jlgaddis 9y ago
    AFAICT, blockchain is the new hammer that is the solution to all of the world's problems.
shakna 9y ago
Sounds like you might like Fossil. [0] I don't see git reaching beyond what it does right now, but a few others do, though they all involve a learning curve. [0] https://www.fossil-scm.org https://www.fossil-scm.org
TomasHubelbauer 9y ago
What software aside from Git Appraise (decentralized code reviews) and Git Dit (decentralized issue tracking - alpha quality) do you know of that could be used to move more of what is kept in GitLab/GitHub/BitBucket databases into Git objects and Git tree in order to make Git decentralized again?
rightos 9y ago
> We need issues, pull requests, comments, milestones, wiki, etc... all to be decentralized. No reason this stuff cannot be modeled using existing Git objects. https://www.fossil-scm.org/ https://www.fossil-scm.org/ pretty much does this.
- tyingq 9y ago
  That is pretty interesting and does model those things in the same data store. But the data store isn't git objects, as far as I can tell... "Fossil stores its objects in a relational (SQLite) database file"
  - rightos 9y ago
    Yeah, it fully replaces the whole version control tool.
epicide 9y ago
I think git-the-tool (i.e. the CLI tool) makes sense to be decentralized as it's at the core. If that tool were built around the idea of a central repository (like SVN), then you cannot escape that centralization (without using what are effectively hacks). I don't think it is wrong to then choose to have a centralized workflow on top of it. There are tradeoffs for either one, so choose what works best for your team. For example, I couldn't imagine trying to onboard new client employees to a project without having some sort of centralized single-point-of-truth repository. Getting them to grok GitHub (and friends) is hard enough, sometimes.
yellowapple 9y ago
You could always use all three. That way, if one goes down, there are still two others ready to take its place.

exikyut 9y ago

1. Businesses need a "halp everything is on fire" button that costs them $1000 a second but will fix EVERY issue, (virtually) guaranteed by SLA. Ultimately that is what these orgs provide; the hosting is kind of almost secondary to that. 2. Actually building real-world implementations of "Issues, pull requests, comments, milestones, wiki, etc..." requires top-tier engineer[ing] time and energy to build and maintain. The current Git-on-steroids-aaS approach provides a very successful way to fund that undeniable cost.

hobofan 9y ago

> No reason this stuff cannot be modeled using existing Git objects. That's the easy part. The hard part is discovery and keeping stuff like teams and moderation when you decentralize it. Advancements in Blockchain-tech, IPFS and similar will make this viable soonish-ly, but I think we are not quite there yet from a technological standpoint.

sillysaurus3 9y ago
How is blockchain related to this?
- rightos 9y ago
  Didn't you get the memo? If you stamp enough buzzwords on everything, it magically works, regardless of their relevance to the application.
  - hobofan 9y ago
    I see you got the memo that being dismissive of everything that contains buzzwords is still popular ;) Both IPFS and blockchain are definitely applicable to decentralizing applications. E.g. DSound[0], a distributed version of Soundcloud is built with IPFS + a blockchain(not necessarily a fan of STEEM though). There could just as well be something analogous for Github, Bitbucket, etc.. [0]: https://steemit.com/music/@prc/introducing-dsound-a-decentralized-sound-platform-using-steem-and-ipfs https://steemit.com/music/@prc/introducing-dsound-a-decentra...
- hobofan 9y ago
  Blockchains allow for a distributed, mutable permissioned system that are required(?) for features like "Who is allowed to push to this named repository?". You can also leave stuff like that out, but then you will end up with a system where everyone can only push to their own forks leaving us with a very splintered distributed system. To compensate we would need a much better system for distributed content discovery than anything I've seen so far.
  - icebraining 9y ago
    You don't need a Blockchain for that. You just store the public keys of the allowed users on the repository itself. Giving readable names to repositories is a possible use case, although I'd just use DNS.
    - hobofan 9y ago
      Yeah, I guess you are right, a blockchain is probably not an absolute requirement for that. I think though, that decentralized maintenance of open source project would be a logical next step, and a blockchain-based system could certainly be useful there. This could help prevent a lot of stale/abandoned projects from dying where the only maintainers of a project leave it to rot and there is no one left to review PRs coming from the community.
      - icebraining 9y ago
        How would the blockchain help there?
  - deleted 9y ago
    [deleted]
- deleted 9y ago
  [deleted]
- jlgaddis 9y ago
  AFAICT, blockchain is the new hammer that is the solution to all of the world's problems.

shakna 9y ago

Sounds like you might like Fossil. [0] I don't see git reaching beyond what it does right now, but a few others do, though they all involve a learning curve. [0] https://www.fossil-scm.org https://www.fossil-scm.org

TomasHubelbauer 9y ago

What software aside from Git Appraise (decentralized code reviews) and Git Dit (decentralized issue tracking - alpha quality) do you know of that could be used to move more of what is kept in GitLab/GitHub/BitBucket databases into Git objects and Git tree in order to make Git decentralized again?

rightos 9y ago

> We need issues, pull requests, comments, milestones, wiki, etc... all to be decentralized. No reason this stuff cannot be modeled using existing Git objects. https://www.fossil-scm.org/ https://www.fossil-scm.org/ pretty much does this.

tyingq 9y ago
That is pretty interesting and does model those things in the same data store. But the data store isn't git objects, as far as I can tell... "Fossil stores its objects in a relational (SQLite) database file"
- rightos 9y ago
  Yeah, it fully replaces the whole version control tool.

epicide 9y ago

I think git-the-tool (i.e. the CLI tool) makes sense to be decentralized as it's at the core. If that tool were built around the idea of a central repository (like SVN), then you cannot escape that centralization (without using what are effectively hacks). I don't think it is wrong to then choose to have a centralized workflow on top of it. There are tradeoffs for either one, so choose what works best for your team. For example, I couldn't imagine trying to onboard new client employees to a project without having some sort of centralized single-point-of-truth repository. Getting them to grok GitHub (and friends) is hard enough, sometimes.

yellowapple 9y ago

You could always use all three. That way, if one goes down, there are still two others ready to take its place.