4 ms·

> 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 no

> 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.
      - pdonis 7y ago
        > You can set up a backup Github? I can put a cloned backup of a git repository anywhere I want. (I do this with all my git repos; I certainly don't depend on Github--or Gitlab, or anyone else--to keep the only copies that aren't on my local machine.) I can't back up the other data that Github stores (issues, wiki, etc.), but that's because Github gives no way to download it, not because Github is "centralized". Github could provide the capability to download this data if it wanted to, without changing its underlying storage model at all. It just doesn't want to. > when there is an issue with Github your team and deployment methods (CI/etc) would automatically switch to that backup If what you are providing is "better failover performance than Github", that's fine (although I would want to see your actual uptime numbers before I'd believe any such claim), but that's not what "decentralized" means. > 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. Sure, but unless you think Github literally stores all of their data on one single server machine, then Github itself is "distributed" in the same sense. > I'm a bit confused at your question. Are you asking why being distributed is good? No, I'm asking why you keep on saying "decentralized" when it turns out that what you mean is "distributed" (and when even "distributed" isn't the real issue--see below). They're not the same thing. You keep saying "decentralized is better than Github", but benefits like better failover performance come from being distributed, and Github is distributed, as I just pointed out above. > you're asking why someone might not want centralization for the rest of the non-Git components[1]? If your argument is "the rest of the non-Git components shouldn't be locked up in Github's data centers where nobody else can download them", that's fine, but it has nothing whatever to do with "decentralized" or even "distributed". You're just saying that all those other things should be in a freely accessible data store that can be cloned and replicated and accessed just like the git repo for the code itself. Sure, that's fine, I agree. But all this talk about "decentralized" has nothing to do with that point; it just obfuscates it.

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.
    - pdonis 7y ago
      > You can set up a backup Github? I can put a cloned backup of a git repository anywhere I want. (I do this with all my git repos; I certainly don't depend on Github--or Gitlab, or anyone else--to keep the only copies that aren't on my local machine.) I can't back up the other data that Github stores (issues, wiki, etc.), but that's because Github gives no way to download it, not because Github is "centralized". Github could provide the capability to download this data if it wanted to, without changing its underlying storage model at all. It just doesn't want to. > when there is an issue with Github your team and deployment methods (CI/etc) would automatically switch to that backup If what you are providing is "better failover performance than Github", that's fine (although I would want to see your actual uptime numbers before I'd believe any such claim), but that's not what "decentralized" means. > 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. Sure, but unless you think Github literally stores all of their data on one single server machine, then Github itself is "distributed" in the same sense. > I'm a bit confused at your question. Are you asking why being distributed is good? No, I'm asking why you keep on saying "decentralized" when it turns out that what you mean is "distributed" (and when even "distributed" isn't the real issue--see below). They're not the same thing. You keep saying "decentralized is better than Github", but benefits like better failover performance come from being distributed, and Github is distributed, as I just pointed out above. > you're asking why someone might not want centralization for the rest of the non-Git components[1]? If your argument is "the rest of the non-Git components shouldn't be locked up in Github's data centers where nobody else can download them", that's fine, but it has nothing whatever to do with "decentralized" or even "distributed". You're just saying that all those other things should be in a freely accessible data store that can be cloned and replicated and accessed just like the git repo for the code itself. Sure, that's fine, I agree. But all this talk about "decentralized" has nothing to do with that point; it just obfuscates it.