> In a centralized vcs, that history is always mediated by the server - you want a new revision number, you have to ask the server what it is. I assume the mos

> In a centralized vcs, that history is always mediated by the server - you want a new revision number, you have to ask the server what it is. I assume the most trivial case when say I contribute to e.g. MS documentation, which source is now available exclusively on GitHub. Can I say that this MS docs repository is a canonical copy? I think that the most common daily use workflows with git and GitHub are absolutely centralised regardless of the decentralised nature of git. * I have a local git repository, its local version history and all the great features this provides. But I have to push to GitHub, you know. Can I somehow publish my changes if GitHub is down? So how is this different from centralised version control? * GitHib provides extra features besides version control. It has a bug tracker, wiki, whatever. I'm tied to all these features, and they are not decentralised at all. I understand that this analogy is silly, but GitHub is a well done SourceForge with Git. But it's still SourceForge, and it's centralised. When I use git with GitHub, I usually only clone, commit and push and check my project's issue tracker. All these actions except commit require access to GitHub. So I think that the workflow is absolutely centralised even if git is decentralised by design and has local version history. I think that's what @evouga meant in his comment above when he said > But almost nobody actually uses git the way it was originally intended, eg. as decentralized version control? Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to.