> >"Time for a decentralized version control system?"
I have to laugh at this one. Git is a decentralized VCS, that was effectively re-centralized (via Github) for the sake of convenience.
I have to laugh at this one. Git is a decentralized VCS, that was effectively re-centralized (via Github) for the sake of convenience.
Of course, there is the benefit of a VCS built on the idea of decentralization: not having to be online to make commits (cough SVN cough). But, in theory, could a centralized system work in “offline mode” like Git?
That's one way of doing it. There are others as well.
https://git-scm.com/book/en/v2/Distributed-Git-Distributed-W...
But, one relatively decentralized workflow that git has good support for is sending patches via email (git format-patch, git am). I believe the Linux kernel still does a large amount of its collaboration that way.
https://github.com/FFmpeg/FFmpeg/pull/153#issuecomment-15416...
Git is a _distributed_ version control system, not a decentralized version control system. This simply means that users of the repository download the entire repository onto the machine they are making changes from. Distributed version control systems have no opinions on whether the source of truth for a given repository is decentralized, distributed, or centralized.
The key point about git is that every copy of the repository is semantically equivalent to every other copy. The one on your local machine is a fully fledged repo just like the one on your colleague's machine and just like the one on github or wherever else a "canonical repo" is hosted.
This is utterly different from older systems like svn or perforce, where the "central server" is semantically distinct from whatever you have on your machine.
At any time, you could decide that a different instance of the repo is canonical (shared push/pull), and that's what make git decentralized.
Yes. Instead of github.com/username/project people host git repos on their own machines.
That is exactly how Linus designed it to be used, and how it was used in the early days.
You clone a maintainers personal tree (which can be anywhere), make the change, and email them the patch with git send-email. They then apply it with git am -3. Trusted maintainers might tell another maintainer to pull their tree from wherever they put it, but they can place it wherever in the moment, including just on their own machine - it only needs to work for a single fetch as well, and could be a new location every time.
In a true decentralized system (e.g. Bittorrent, Bitcoin, etc.) it's practically impossible to delete something, and there would be plenty of accessible copies of data in jurisdictions that are out of reach of any single country's law enforcement, and even out of reach of the original creator to delete, so the original creator's government would not be able to force them to delete it.
Another HN user pointed out Freenet to me in another post, which sounded a lot like the right answer, but I haven't researched it in detail yet and whether it could be easily adapted to work with the git command to actually version repos in a decentralized fashion.
I thought this was what decentralised means in the VCS parlance ... that you have more than one “upstream” rather than a single, central one.
Distributing node lists is sort of a solved problem isn't it?
Some time ago, I and a friend worked together on a project in a place where there was no centralized git server; both of us ran git-daemon (https://git-scm.com/docs/git-daemon) on our desktops, and we often pulled from the other as we developed each feature. It was fun, and worked really well.
Git is truly decentralized, in that each developer has a full copy of the code and its history, and any of these copies can be used as the source for other copies.
> In a true decentralized system (e.g. Bittorrent, Bitcoin, etc.) it's practically impossible to delete something, and there would be plenty of accessible copies of data in jurisdictions that are out of reach of any single country's law enforcement, and even out of reach of the original creator to delete, so the original creator's government would not be able to force them to delete it.
That's how it works with git; everyone who cloned the repository to their desktop (for instance, to develop and contribute a patch) has a full copy of the history up to that moment, and that copy is out of the reach of both other jurisdictions and the original creator. There's no way to even know how many of them there are, much less who has them.
But this doesn't solve the problem of how arbitrary public should locate and access those copies. If the code isn't accessible by its intended users, it effectively doesn't exist.
Git was designed to be distributed in the sense that people work on a local copies of their code which they then reintroduce into the project.
Projects themselves are not supposed to be decentralised, there is supposed to be a single point of truth which represents the collaborative effort of everyone working on it. And that's what needs to be hosted somewhere, and everyone needs to agree on it. What even would be the point of any kind of version control if you have hundreds of competing top level codebases?