5 ms·

Perhaps the Sia node gives you access to a "master" repo. Aka a single entity that represents a centralized repo, but hosted on a decentralized system. Not sur

Perhaps the Sia node gives you access to a "master" repo. Aka a single entity that represents a centralized repo, but hosted on a decentralized system. Not sure though.

lucideer 7y ago
There's no such thing as a "master" repo in Git. "origin" is the default name for a cloned remote, and the convention used for adding a default remote, but nothing distinguishes the origin remote from any other remote. It isn't a master remote other than being default. One could add a Git remote (and name it "origin") that's backed by a decentralised system currently: e.g. one could do: git remote add origin ./some/ipfs/mount
- asdkhadsj 7y ago
  > There's no such thing as a "master" repo in Git. "origin" is the default name for a cloned remote, and the convention used for adding a default remote, but nothing distinguishes the origin remote from any other remote. It isn't a master remote other than being default. You're over thinking my example. As I said, by "master" repo I meant the centralized repo that many _(most?)_ git users have, somewhere. Aka Github, Gitlab, etc. You're conflating Git's design with users patterns of centralization and distributed teams. Notably that often there is a single, centralized branch(es) on a single repo that everyone merges to. This centralization could be distributed. It sounds trippy, but as you put it if your origin is on IPFS, you effectively have a single, mutable repo instance hosted on a decentralized platform (IPFS). My guess is that is what Dgit is. A single mutable instance, hosted on a decentralized platform (Sia). So back to my example, many people do indeed have a "master"/centralized repo. It's not a part of git, it's a user convention on top of git. But I didn't say it was in git.
  - pdonis 7y ago
    > hosted on a decentralized platform (IPFS) What's the difference between this kind of "decentralized platform" and GitHub?
    - jddj 7y ago
      There was that thing a few months* back about Iranian software devs losing GitHub access due to the newer sanctions. Presumably if you were to host on IPFS it would be more difficult for people to cut you off like that. What's the practical difference between you pinning your own IPFS node and just self hosting? Pass. * Years? Time is weird at the moment.
    - asdkhadsj 7y ago
      Theoretically the difference is that it is.. well, distributed. Aka any benefits you'd attribute to having a file on IPFS over Github could apply here. Which is to say, if Github goes down, gets blocked, blocks your team, etc; your team can still push to the "centralized" repo, etc etc.
      - pdonis 7y ago
        > if Github goes down, gets blocked, blocks your team, etc; your team can still push to the "centralized" repo, etc etc. But as others have pointed out, I can set up such a backup anywhere. What is the advantage of this particular way of doing it?
        asdkhadsj 7y ago
        You can set up a backup Github? So you mean, you'd run like, an in-sync Gitea or Gitlab, and when there is an issue with Github your team and deployment methods (CI/etc) would automatically switch to that backup (temporarily or permanently)? That seems.. convoluted. I feel like I'm repeating myself, but the advantage is being distributed. Distributed systems usually aim to be resistant to these types of issues. I'm a bit confused at your question. Are you asking why being distributed is good? Or are you asking why being distributed is good in this case? If you're asking the former, I don't think this convo is in scope of explaining distributed vs centralized. If you're asking the latter, why would this case be any different than any other case? You have a centralized entity and a while bunch of community and tooling built around it. Why wouldn't you prefer that out of control of a single entity? The very argument against centralization is built into the foundation of Git itself. Yet you're asking why someone might not want centralization for the rest of the non-Git components[1]? [1]: "non-Git components", While the source code is tracked via Git, I just mean the centralized entity your CI/CD/etc is hooked up to is it's own thing.

Perhaps the Sia node gives you access to a "master" repo. Aka a single entity that represents a centralized repo, but hosted on a decentralized system. Not sure though.

lucideer 7y ago

There's no such thing as a "master" repo in Git. "origin" is the default name for a cloned remote, and the convention used for adding a default remote, but nothing distinguishes the origin remote from any other remote. It isn't a master remote other than being default. One could add a Git remote (and name it "origin") that's backed by a decentralised system currently: e.g. one could do: git remote add origin ./some/ipfs/mount

asdkhadsj 7y ago
> There's no such thing as a "master" repo in Git. "origin" is the default name for a cloned remote, and the convention used for adding a default remote, but nothing distinguishes the origin remote from any other remote. It isn't a master remote other than being default. You're over thinking my example. As I said, by "master" repo I meant the centralized repo that many _(most?)_ git users have, somewhere. Aka Github, Gitlab, etc. You're conflating Git's design with users patterns of centralization and distributed teams. Notably that often there is a single, centralized branch(es) on a single repo that everyone merges to. This centralization could be distributed. It sounds trippy, but as you put it if your origin is on IPFS, you effectively have a single, mutable repo instance hosted on a decentralized platform (IPFS). My guess is that is what Dgit is. A single mutable instance, hosted on a decentralized platform (Sia). So back to my example, many people do indeed have a "master"/centralized repo. It's not a part of git, it's a user convention on top of git. But I didn't say it was in git.
- pdonis 7y ago
  > hosted on a decentralized platform (IPFS) What's the difference between this kind of "decentralized platform" and GitHub?
  - jddj 7y ago
    There was that thing a few months* back about Iranian software devs losing GitHub access due to the newer sanctions. Presumably if you were to host on IPFS it would be more difficult for people to cut you off like that. What's the practical difference between you pinning your own IPFS node and just self hosting? Pass. * Years? Time is weird at the moment.
  - asdkhadsj 7y ago
    Theoretically the difference is that it is.. well, distributed. Aka any benefits you'd attribute to having a file on IPFS over Github could apply here. Which is to say, if Github goes down, gets blocked, blocks your team, etc; your team can still push to the "centralized" repo, etc etc.
    - pdonis 7y ago
      > if Github goes down, gets blocked, blocks your team, etc; your team can still push to the "centralized" repo, etc etc. But as others have pointed out, I can set up such a backup anywhere. What is the advantage of this particular way of doing it?
      - asdkhadsj 7y ago
        You can set up a backup Github? So you mean, you'd run like, an in-sync Gitea or Gitlab, and when there is an issue with Github your team and deployment methods (CI/etc) would automatically switch to that backup (temporarily or permanently)? That seems.. convoluted. I feel like I'm repeating myself, but the advantage is being distributed. Distributed systems usually aim to be resistant to these types of issues. I'm a bit confused at your question. Are you asking why being distributed is good? Or are you asking why being distributed is good in this case? If you're asking the former, I don't think this convo is in scope of explaining distributed vs centralized. If you're asking the latter, why would this case be any different than any other case? You have a centralized entity and a while bunch of community and tooling built around it. Why wouldn't you prefer that out of control of a single entity? The very argument against centralization is built into the foundation of Git itself. Yet you're asking why someone might not want centralization for the rest of the non-Git components[1]? [1]: "non-Git components", While the source code is tracked via Git, I just mean the centralized entity your CI/CD/etc is hooked up to is it's own thing.