I'd argue that even a single developer really benefit from a "centralized" repository. It helps with maintainability, backups, syncing between machines (oh, my workstation wasn't on, can't update my laptop...).
Pulling code from random developers machines might sound pretty neat in isolation but that is the exception and an edge case to something else. And that something else should most likely be a centralized repository.
When people say they love decentralized version control I often get the impression that what they really love is local commits. There is nothing that says that you can't have local commits in a centralized version control system, it is just that being decentralized is a neat solution for many problems. But that is just an implementation detail that very few could care about, had it not been hyped to death.
Now this is something entirely different than the whole developer community putting everything in one basket (github), that's the only type of centralization worth worrying about.
Isn't that just a straw man argument?
To the extent that it applies to distributed version control, it seems like an invented problem (i.e. I don't know anyone who uses a dvcs that pulls from 'random' developers). To the extent that it is true (we are all probably guilty of using code from developers we don't know and have not properly vetted) i t seems like just as much---if not more of a problem---with github-esque projects.
> I often get the impression that what they really love is local commits
That's a really good point I have not considered before. So would you say that git's main contribution to the development community is showing the power of a VCS with local commits? And that's why github is dominating core git?
That was in fact one of the arguments a few true believers used in favor of DVCS when it was still a novelty.
The think I think truly gives developers comfort, in addition to all the nice features it makes simple, is LOCKSS (Lots of Copies Keeps Stuff Safe). When everyone has a full copy of the repo, even if you generally work through an intermediary, the central repo being blown away or taken control of by a bad actor doesn't mean you need to reconstruct the history of the code from whatever single snapshot checkouts individuals happen to have.
That said, I will agree that the workflows enabled, as well as the power of a common platform, are probably what really let git and github become the new default.
edit: Also I imagine being able to paw through the entire history and bisect entirely locally are vital features for a small (but essential especially of open source) minority of developers.
The point being that short of choosing a convention for which person’s copy (or which machine, etc) counts as the primary source of record (which would then just be poor man’s centralization with the admin costs and maintenance of any centralization tools now a burden on the team rather than a third-party product), then interacting in an ad hoc way with even just my known team’s set of distributed clones of the project turns into a bookkeeping problem nobody wants.
I can also imagine a non-centralized model can lead to many more complicated workflow failure modes. I’m just thinking about how often novices get stuck with rebasing errors or squashing commits incorrectly, and bikeshedding arguments over whether it’s ok to ever revert master or if you should intentionally keep mistakes in the history and correct with new commits. I can imagine it being even worse when there are fewer conventions, since conventions are often the only way to avoid these bikeshedding debates about preferred git hygiene methods.
But the servers are necessary, as far as I know, unless you want to enumerate IP addresses and scan for open ports. Which is going to be interesting with IPv6.
In theory, yes, if they go down, you could configure your client to point at another well-known client, though.
Of course some (many) people are using forks, but all sync directly or indirectly with this dude's version.
Linux kernel dev branch single source of truth is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
The stable branches have their single source of truth repositories, too.
There is a single source of truth for a particular version of Linux.
A few days ago I read about the multiple Linux distributions that all have their fork with special patches etc. pp.
Sure you CAN use git without a web UI, We had that at work for a while and it was not a good experience at all compared to using gitlab which we have now and we now have so many features that let us get things done faster.
What I'd personally like to see is a repo viewer similar to Github but implemented purely in JavaScript and cloning repos in the fly just like the native git does. Git.js (https://github.com/yonran/git.js) has something like that but it looks old and ugly.
I'm not arguing against your suggestion, but these are things that need to be solved if this workflow is ever going to see mainstream adoption. Network infrastructure and security has been geared towards centralization for a long time. That's going to need to change if we want to empower distributed applications of this nature (which I believe we do).
Well, actually I wasn't suggesting that, just emphasizing git's distributed nature.
What I do suggest is a federated model, large number of small hosts akin to Mastodon. What would be the real issue is, like you noted, discovery. Centralized solutions have it nicely solved but it's hard to do in general with decentralized ones.
As opposed to the traditional version control model where, e.g. every commit effectively requires a rebase against the remote and the history cannot be retrieved without a connection to the remote.
The "D" in "DVCS" is about having many copies of the repository, not about having _no_ central repository, which is still a core part of having an effective delivery workflow and very much encouraged by the baked-in concept of a default remote repository.
It's a distinction of technology, not of workflow.
This is really a common misunderstanding about what makes DVCS an effective concept.
In retrospect I think it makes complete sense to tie code, documentation and issues. They evolve together, maybe they ought to be versioned together.
I feel like code reviews naturally should be stored alongside the code it's reviewing, and like the PoC shown by git-appraise from Google[0]
The web itself seems to be be becoming more centralised- more people spend more time on fewer websites. Websites are increasingly being hosted on a tiny number of mega cloud services, rather than millions of independent server rooms.
Centralisation is a real concern.
Tools like this primarily provide a web client to a repository not intended as a working copy, with some optional non-git code collaboration tools, such as issues, and an inbox of pull requests (i.e. suggested patches). These are not unique tools, there are many options for issue tracking and email.
I make this point because these solutions are trying to replicate smaller or larger chunks of github rather than provide alternative ways to use git.
That said, Gita/Gogs is pretty. And might hold the hand of people only used to github. It is great that it is self-contained as a binary, so can be used with minimal configuration, like other front-ends.
But I worry that the emphasis on tools like this suggest we have accepted that github-flavoured centralised version control ('gitversion', maybe, or 'gcs'), rather than git, is now the de facto standard for version control. Am I paranoid? Does it even matter?