Including ssh, of course. `git clone $USER@example.com:/tmp/blah.git`, and `git init --bare` (for a non-checked-out, non-working-dir, "just the .git folder" file location).
Each developer workstation had a git user with ssh enabled and restricted to some git invocation I can't recall, and chgrp git / chmod g+rwS a conventional path, and remotes named from team members. PRs were literally that: either emails or one shouting to another over our desk that someone could git pull from one's machine straight from their (non-bare) repo.
The whole development process was entirely decentralised, any one's machine was as worthy as the next one and there was no single point of failure.
This experience started on a self-hosted SVN + Hudson server (not VM). That server was repurposed to run ESX that the hosted the VM of its former self. Which felt a bit pointless.
Then we moved to git from svn but kept everything else the same. Had groovy scripts coming out of our build and deployment ears. shudder
and if you start bragging about the "decentralization"... well, there is a reason anyone now uses a gitHUB, where there is a proper, centralized, version online
Linux has a proper, centralized, version online. Still their collaboration workflow (they use the email workflow) is decentralised.
I think everybody uses GitHub now because they don't know the email workflow, and it's more convenient to have one account on GitHub than having one account on every instance of GitLab you contribute to. And I guess most people only know the GitHub web interface and don't really feel like using something else.
My point being that there are many reasons why everybody is using GitHub, but it does not mean that the PR workflow is better. What do you think?
They may look like centralized repositories but they are not. We have our own local repositories, sometimes even more than one for the same project, and we use the GitHub or Bitbucket one only to sync some branches between developers.
It's not what used to be with centralized systems. The only copy of the repository was on the server. Locally developers only had files sometimes with a global lock such that nobody could work on the same file at the same time.
That's the real advantage of having a system like git in combination with a server like GitHub.
The PRs are nice but not everybody use them. Sometimes it's only merge and push.
I would say that it is the real advantage of having a system like git, period. Right?
My customers and nearly everybody else prefer a hosted solution like GitHub.
The LKML [mirror][] has a page with links to the various lists, but if you dig around in those links, there doesn’t appear to be a way to post new items or reply to existing messages in a browser. It’s just text - The mechanism of action is still sending emails to various handles to perform these activities.
It means that I can choose a client that works for me. Whereas I cannot choose the UI I want for GitHub.
Initially, after a git-svn period we set up bare git+ssh on it as a direct replacement but we quickly realised it was annoying and suboptimal, and that we could just set the same thing up decentralised, adjusting our habits for the better.
It's so refreshing to use, everything is a git fetch --all away (including tags), e.g no more "I forgot to push before going on holidays" or otherwise surprise sick leave, we'd just power up the machine and not even log in, sshd would start, git fetch, and power down via the login manager or ACPI event.
enter two companies to rip off and monetize gitosis/gitolite, and eventually rewrite them into their own service, and presto, everyone has forgotten that git is both free and decentralized