3 ms·

"If [...] you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations." Github has a nice, documented

by theamk 5y ago

"If [...] you decide you want to self host git over ssh or something, you lose the history of all your issues and conversations." Github has a nice, documented API to export issues, including issue history. Many open source tools, including Gitlab, are happy to import that list into their own database: https://docs.gitlab.com/ee/user/project/import/github.html https://docs.gitlab.com/ee/user/project/import/github.html Granted, this has a problem if Github suddenly, without any warning, decides to turn off that API. Or if it goes down and loses data permanently. I find both of those scenarios pretty unlikely, but it you are worried about them, it should be pretty straightforward to have some sort of export script in cronjob, to keep a local copy of issue database.

josephg 5y ago
Sure; github has the ability to export its data via centrally managed APIs. My point is that tying a bunch of centralized data (access control, issues, discussions, PRs, wiki, etc) to the decentralized data store of git's source control undermines many of git's best features. It makes git a de-facto centralized system. Centralized systems aren't bad per se, but the combination is incoherent. Github's architecture has some of the worst parts of decentralization, combined with some of the worst parts of centralization. Eg, Git's decentralized nature makes it extremely hard to evolve. (See: the desire to move from SHA1 to something more modern.) And we don't really get the benefits of a decentralized system, because I can't interact with issues while I'm offline, or while github is offline. And we're all locked in to github's ecosystem. We can only fully interact with our opensource projects on github with permission, ironically, from Microsoft. And I don't know if I trust any big tech company enough to assume they'll remain a good stewardship over the world's opensource code. The decentralized data store is right there in the middle of every github project. I wish github thought to use it.
- theamk 5y ago
  Well, Github did use decentralized data storage -- the wikis are implemented as directories full of markdown files. You can clone it to your PC and view locally, push/pull the changes, etc... In addition, you can use your repository as wiki directly -- with markdown rendering, and "edit" button in web UI, just having "docs/" full of .md files gives you pretty passable wiki. But it seems that very few people care. How many people mirror wikis of their favorite projects, or backup their issues? I know only one such person, myself. I think that for some types of data, distributed model with operations like "clone with full history", "pull", "merge", etc... makes very little sense. For example access control -- why would you ever want to clone this? If I set up a mirror of repo, I don't want to give their authors access by default. Same goes for discussions -- for a good discussion you want all members to see their own replies. Having original post appear on sites A, B, C; and reply 1 on sites A, B while reply 2 appears on sites B, C will be super confusing to users, and will likely just cause platform to be abandoned. And a lot of times, ticket list is better off shared, so people can coordinate the work they do even if they have their own fork. Once you realize a lot of supporting services need to be centralized, all you can use "git" for is for data distribution. Is git better than SMTP for mailing list discussions? Is git better that SMTP / REST API for ticket list? Maybe, maybe not. But ultimately it does not matter, because most people do not care about mirroring stuff locally, and those who do care, can already achieve it.

by theamk 5y ago

josephg 5y ago

Sure; github has the ability to export its data via centrally managed APIs. My point is that tying a bunch of centralized data (access control, issues, discussions, PRs, wiki, etc) to the decentralized data store of git's source control undermines many of git's best features. It makes git a de-facto centralized system. Centralized systems aren't bad per se, but the combination is incoherent. Github's architecture has some of the worst parts of decentralization, combined with some of the worst parts of centralization. Eg, Git's decentralized nature makes it extremely hard to evolve. (See: the desire to move from SHA1 to something more modern.) And we don't really get the benefits of a decentralized system, because I can't interact with issues while I'm offline, or while github is offline. And we're all locked in to github's ecosystem. We can only fully interact with our opensource projects on github with permission, ironically, from Microsoft. And I don't know if I trust any big tech company enough to assume they'll remain a good stewardship over the world's opensource code. The decentralized data store is right there in the middle of every github project. I wish github thought to use it.

theamk 5y ago
Well, Github did use decentralized data storage -- the wikis are implemented as directories full of markdown files. You can clone it to your PC and view locally, push/pull the changes, etc... In addition, you can use your repository as wiki directly -- with markdown rendering, and "edit" button in web UI, just having "docs/" full of .md files gives you pretty passable wiki. But it seems that very few people care. How many people mirror wikis of their favorite projects, or backup their issues? I know only one such person, myself. I think that for some types of data, distributed model with operations like "clone with full history", "pull", "merge", etc... makes very little sense. For example access control -- why would you ever want to clone this? If I set up a mirror of repo, I don't want to give their authors access by default. Same goes for discussions -- for a good discussion you want all members to see their own replies. Having original post appear on sites A, B, C; and reply 1 on sites A, B while reply 2 appears on sites B, C will be super confusing to users, and will likely just cause platform to be abandoned. And a lot of times, ticket list is better off shared, so people can coordinate the work they do even if they have their own fork. Once you realize a lot of supporting services need to be centralized, all you can use "git" for is for data distribution. Is git better than SMTP for mailing list discussions? Is git better that SMTP / REST API for ticket list? Maybe, maybe not. But ultimately it does not matter, because most people do not care about mirroring stuff locally, and those who do care, can already achieve it.