I thought it originated in a decentralized git use case where developer A asks developer B to pull their proposed new code into their (local) repo. So predating server hosted git. Perhaps I made that up though.
That's generally my point: despite the server presenting itself as a centralized "hub", it is really just another decentralized user of a decentralized git repo.
From a git perspective, there is no meaningful difference between server and client.
i prefer to talk about a project's "canonical repository". so for example, the main project i work on has two primary developers, each of us doing a bunch of mostly independent work. we could set things up so that we simply push/pull between those two repositories.
but that's a much less useful way to work than to denote a repository somewhere as the "canonical" one, and then all those involved pull from it and push to it.
the presence/absence of a server associated with a repo is a bit of a red herring - what matters is the workflow associated with the different repos. my own repo is just a local private one of no particular significance, as is that of my colleague. by contrast, git.ardour.org is canonical (and, as an aside, github.com/Ardour/ardour is merely a mirror).
I like the way L. Torvalds explained here https://www.youtube.com/watch?v=4XpnKHJAok8 where he refers to the circle of trust. A group of developers that each share a copy of the project. Very democratic. Within the circle of trust, of course.
Except that there is no such canonical repository. I can set your laptop as a remote and pull from you. You can set my raspberry pi as a remote and pull from me. There is no such thing as a “canonical” repository in git. Such a concept only exists in the systems built on top of git, if it exists at all.
No, no, you misunderstand. The canonical repository is just an agreement among developers. Nothing more (other than a bit of infrastructure to enable it).
