[mbreese]

Git itself is decentralized. It is entirely agnostic from a centralized/decentralized point of view. We tend to centralize things to make life easier. Who wants to pull updates from each contributor as opposed to a hub?

So the real question is — what are the features of GitHub would you like to see decentralized? CI? Issues? Wikis? Because, you can self host many of these with gitea, GitLab, or sr.ht. That’s the best kind of decentralization, but it does add to your own personal overhead (maintenance, backups), and really limits discovery.

I think what you might be asking for is if there is a federated code repository that supports git. That’s an interesting question, and I don’t know if such a thing yet exists.

[sreevisakh]

> I think what you might be asking for is if there is a federated code repository that supports git. That’s an interesting question, and I don’t know if such a thing yet exists.

Sourcehut itself is fully federated if you are willing to learn email workflow. You don't need to register an account anywhere to collaborate on sourcehut. That include feature requests, bug reports, discussions, submitting patches and even pull requests from any public repository anywhere [1]. The discussions also exist on mailing list archives and personal mailboxes. They are not lost even if you decide to change host.

But developers are extremely resistant to email workflows. When I suggest it, people react as if I am suggesting black magic. But in my experience, email workflow isn't that unpleasant. Most of the problems with email workflow are due to poor email clients (issues with plain text, composing, rendering and threaded displays). Setting up git and a good but simple email client for git is not a hard task. The rest of the workflow is actually very pleasant.

[1] https://git-scm.com/docs/git-request-pull

[nine_k]

- Code review aka pull requests.

- Issues.

- CI.

- "Home page" with the readme.md rendered.

Easy discoverability is a large concern. Easy discussion with fast round-trips and a trail is important (email or NNTP can help here though). CI is a thing that may need a serious effort to get running smoothly.

These things are centralized because it's easy to implement them once in one place instead of reinventing. But if there'd be an obvious and bullet-proof way to have them replicated (like in Fossil), the need for strict centralization would wane.

Discoverability would still be an issue though. It's like torrents: completely decentralied, but without a directory like TPB it's really hard to find them.

[quickthrower2]

Is it possible to decentralize "I know about package X -> Find Package X online -> Git Clone"?

While keeping the property of very high availability? And making it convenient.

I think the first two steps could be covered by a source search engine that spans different repository providers, and includes self-hosted git instances.

That source search engine will probably be centralized, although if we are just searching names and descriptions (and not code) the engine could be a fairly small .zip file that anyone can install. So comes down to "passing around lists".

[mbreese]

That’s the idea with pkg.go, npm, pypi, CRAN, (CPAN?!?), etc… discovery of packages. I think each of these has a wider record for the package showing where individual code repositories are hosted. But I wouldn’t necessarily call them “convenient.”

But that isn’t helpful for cross-language searching, or a code search engine (which I think is a great idea).