You don’t need a daemon. You can push and pull to any url, including file urls
as long as you have access to the url(e.g. local file permission or network authentication with a samba server, or a shared folder on another pc), you can use it as a remote
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).
Back when GitHub was in infancy, git-web was the top crop UI, our tracker was either one of Trac or Redmine, CI was a Hudson/Jenkins hellscape, the world "cloud" referred to water in the sky, reliable VMs were a distant dream, and servers were not cheap, our team of three~four people set up decentralised git over ssh.
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 reads like a chapter out of my own biography.
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
> 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?
All my current customers are using Bitbucket, but it's the same.
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.
One other distinction I would make between this and the email centric workflow that (almost) every mailing list that I know of these days has is the inclusion of a publicly accessible URL with an index of messages.
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.
Yeah to me it's a feature. I don't need everything in a browser. In fact I am happier with dedicated programs (an email client, an FTP server, an IRC client, etc).
It means that I can choose a client that works for me. Whereas I cannot choose the UI I want for GitHub.
That is a much worse setup than what you were replying to. I've seen so many issues caused by centralized version control that Git - and yes, GitHub too - will never experience.
Yup. We moved FROM subversion to that setup. Subversion was hosted on a beige box from the previous era, it was slow as
frack and a ticking timebomb.
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.
yes, and it’s worth mentioning the next step evolution after ssh was gitosis/gitolite to manage who has access to what repos on a single ssh entry point, by taking advantage of the fact that multiple authorized keys could be used for one ssh local user.
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
as long as you have access to the url(e.g. local file permission or network authentication with a samba server, or a shared folder on another pc), you can use it as a remote