Earlier quoted context omitted.
Thanks for the info. Is there a simple way right now to use another storage backend than Sia? E.g. If I have a group of people that want to participate in hosting, but only want to host data from the people in the group? Essentially, can you use dgit to store a repo decentralised without having to set up git synchronisation tools, but while still having control over the hosting infrastructure?
hey cfstras, another dgit dev here. Each repo has a storage adapter specified, so any storage infrastructure is possible, but at this moment we've only written two: sia and on tupelo network. We've had a lot of experience with running IPFS nodes internally, that might be a great option for you in this case? We are in early stages and will add more adapters as feedback informs. Also, its open source and we would love…
Dgit: Git with decentralized remotes
81–87 of 87 posts
Re: Dgit: Git with decentralized remotes
#82Earlier quoted context omitted.
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.
> 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?
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.
Re: Dgit: Git with decentralized remotes
#83Earlier quoted context omitted.
> 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?
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…
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.
Re: Dgit: Git with decentralized remotes
#84Earlier quoted context omitted.
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…
> 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". Gith…
Re: Dgit: Git with decentralized remotes
#85Earlier quoted context omitted.
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…
> 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". Gith…
So.. I think we have a fundamental failure in communication here. It's difficult to discuss decentralization or distributed designs when, well, we can't even refer to the platforms that advertise themselves as such. Ie, I did not make this terminology. The platform we're discussing literally advertises itself as such in this title.
I'm not sure what's even being discussed anymore.
Re: Dgit: Git with decentralized remotes
#86Earlier quoted context omitted.
> 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". Gith…
I'm confused; you object with my use of decentralized, but then argue (it seems) that distributed also does not fit the bill. So.. I think we have a fundamental failure in communication here. It's difficult to discuss decentralization or distributed designs when, well, we can't even refer to the platforms that advertise themselves as such. Ie, I did not make this terminology. The platform we're discussing literally a…
(A) It's decentralized! Woohoo! (I'm paraphrasing.) Which tells me nothing about why "decentralized" is better than GitHub.
(B) It's distributed! Woohoo! (Again, I'm paraphrasing.) Which, again, tells me nothing about why "distributed" is better than GitHub. Not to mention that "distributed" is not the same thing as "decentralized", so if I'm supposed to prefer something like dgit because it's "distributed", the goal posts have been moved.
(C) If GitHub goes down, you can automatically switch to pushing to . Which amounts to "this solution has better failover than GitHub", which, as I noted, (a) might or might not be true (I'd want to see your uptime numbers), and (b) has nothing whatever to do with being "decentralized" or "distributed" since "decentralized" has nothing to do with failover reliability, and GitHub is just as "distributed" as .
(D) You can keep all the "non-git components" in along with the git repo. Which might be an advantage if it's easier to get them from than from GitHub, but, again, has nothing to do with being "decentralized" or "distributed", it just has to do with how accessible makes the "non-git components" as compared with GitHub.
Is there an (E)?
Re: Dgit: Git with decentralized remotes
#87Earlier quoted context omitted.
I'm confused; you object with my use of decentralized, but then argue (it seems) that distributed also does not fit the bill. So.. I think we have a fundamental failure in communication here. It's difficult to discuss decentralization or distributed designs when, well, we can't even refer to the platforms that advertise themselves as such. Ie, I did not make this terminology. The platform we're discussing literally a…
I'm not trying to "discuss decentralized or distributed designs". I'm trying to get somebody to explain to me why I should prefer something like dgit to GitHub on the basis of it being "decentralized" . So far the answers I've gotten are: (A) It's decentralized! Woohoo! (I'm paraphrasing.) Which tells me nothing about why "decentralized" is better than GitHub. (B) It's distributed! Woohoo! (Again, I'm paraphrasing.)…
Yes, I could host my file on Github. However I think it's well beyond my patience to argue for why IPFS(/sia/etc) should exist, in this conversation.
If you see no reason why someone would want to host anything on IPFS/sia/etc over Dropbox or Github, I'm not the person to change your mind.
This discussion merely spawned because I thought I had an idea on what the hell Dgit even is. I didn't write it, have never used it, and know next to nothing about it. Merely, I had envisioned a use case for my team using Git on IPFS, and mentioned that in these comments.