Hacker News Reader

Comment by cookiengineer | Hacker News Reader

What's amazing is that you can also use git locally, without a server, using "git daemon".

I've created a small little bash function for that, and then I just pull from machine to machine (or IP to IP) directly without needing to bother with the internet. Git is very useful this way on hackathons or when there's not much internet bandwidth to begin with.

git-serve() {

    git daemon --reuseaddr --verbose --base-path=$PWD --export-all --enable=receive-pack -- $PWD/.git;

}

View on HN

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

I would have used svn and a proper server.

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.

> That's the real advantage of having a system like git in combination with a server like GitHub.

I would say that it is the real advantage of having a system like git, period. Right?

Yes. I self host my own remote git repositories for personal projects, so I can move commits between my machines without going through a third party.

My customers and nearly everybody else prefer a hosted solution like GitHub.

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.

Not sure I get that. Are you saying that they lack an index of messages?

Not quite - more that there’s a UI on that index.

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.

[mirror]: https://subspace.kernel.org/vger.kernel.org.html

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

This is exactly how I use git in my own projects.

> What's amazing is that you can also use git locally, without a server, using "git daemon".

I don’t think that’s amazing. What was amazing to me was back when I couldn’t set up a Subversion repository without a “server”.

Someone asks on StackOverflow about why `git push` behaves a certain way? The principle of Laziness dictates that you try to reproduce the issue with two sibling directories where one is a remote of the other one. Like they apparently do in one of Git’s integration tests:

    git remote add $1 up ../mirror

You can run a Subversion repository on localhost with the svnserve(1) command:

https://www.visualsvn.com/support/svnbook/ref/svnserve/re/

Yes, another kind of server.

But does it matter? Nowadays even my editor wants to run a server in the background to provide syntax highlighting. People generally don't seem to care and see it as progress.

But what about the price of tea in China? The language servers you refer to provide a decoupled service to other programs. It has literally nothing to do with the fact that I have to (apparently—why would I even use SVN in this day and age) make a dummy repository somewhere hither or tither just so that I can version control my local-only dotfiles!

Or in serverless mode without any server at all. Just open the repository via file://.

Fwiw I think fossil excels for this type of use-case.

Ok, git_noobie here. What is git http-backend [1] for then?

[1] https://git-scm.com/docs/git-http-backend

I discovered this by tabbing git ?TAB in a zsh shell and going through the alphabet.

FYI - no commands starting with e, j, k, o, w, x, y or z using this method. Is there a definitive list of all git commands I wonder?

If you want to use git through a web server, it's one way of doing that. (For example, if you want to use some existing http auth for your users.) You don't particularly need to do that - it's just an option; git over ssh works fine too, as does git with file: local urls (or without "remotes" at all.) Professionally, ssh auth (especially with ControlPersist) has always been the better/faster option, but that's more of a cultural thing.

(My hobby workflow is to just start writing in a directory, and then after a little bit do a "git init"... and then once I have enough to pick a name, I have a "git save-project projectname" script that goes off and does a git init --bare on a homelab server and git push --set-upstream so it's now a remote. Just gradually escalating how "seriously" I'm treating it and therefore how much plumbing I bother with.)

    git help -a

lists all available commands.

It's important to note that the git binaries are (usually) both client and server - by design what with the hole "decentralised" thing.

So the default package will let you run server functionality such as the http-backend (which allows the machine you run it on to serve http(s):// schema repositories)

Sorry, I'm honestly not trying to be snarky, but what's amazing here? `man git-daemon` displays:

> git-daemon - A really simple server for Git repositories

So you can "use git locally, without a server"... by using a server?

Btw you don't need a daemon at all. You can just use file URLs.

How is this different if you work alone, on one machine, and simply don't use a remote?

I realize this is a bastardization of the concept, but for personal projects, it still sounds reasonable.

Reads further...

Eh, I guess USB drives count as separate machines in this case ¯\_(ツ)_/¯

Reply on news.ycombinator.com