Live data from Hacker News

You already have a Git server

maurycyz.com

131–140 of 454 posts

Re: You already have a Git server

#131

I feel like something was lost along the way. git init —-bare will give you a git repo without a working set (just the contents typically in the .git directory). This allows you to create things like `foo.git` instead of `foo/.git`. “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like. You can even namespace where you push back to th…

Git was always explicitly a decentralized, "peer to peer" version control system, as opposed to centralized ones like SVN, with nothing in the protocol itself that makes a distinction between a "server" and a "client". Using it in a centralized fashion is just a workflow that you choose to use (or, realistically, one that somebody else chose for you). Any clone of a repository can be a remote to any other clone, and…

It's a little more complex than that. Yes git can work in a peer-to-peer fashion, but the porcelain is definitely set up for a hub-and-spoke model, given how cloning a remote repo only gives you a partial copy of the remote history.

There's other stuff too, like git submodules can't be configured to reference another branch on the local repository and then be cloned correctly, only another remote.

Re: You already have a Git server

#132

Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?

I've been using git since 2007, this only dawned on me last year. Git is especially prone to the sort of confusion where all the experts you know use it in slightly different ways so the culture is to just wing it until you're your own unique kind of wizard who can't tie his shoes because he favors sandals anyhow.

> all the experts you know use it in slightly different ways

What? Knowing that a git repo is just a folder is nowhere near "expert" level. That's basic knowledge, just like knowing that the commits are nodes of a DAG. Sadly, most git users have no idea how the tool works. It's a strange situation, it'd be like if a majority of drivers didn't know how to change gears.

Re: You already have a Git server

#133

I feel like something was lost along the way. git init —-bare will give you a git repo without a working set (just the contents typically in the .git directory). This allows you to create things like `foo.git` instead of `foo/.git`. “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like. You can even namespace where you push back to th…

Git was always explicitly a decentralized, "peer to peer" version control system, as opposed to centralized ones like SVN, with nothing in the protocol itself that makes a distinction between a "server" and a "client". Using it in a centralized fashion is just a workflow that you choose to use (or, realistically, one that somebody else chose for you). Any clone of a repository can be a remote to any other clone, and…

This is a better summary than mine.

There was a thread not to long ago where people were conflating git with GitHub. Git is an incredible tool (after coming from SVN/CVS/p4/source safe) that stands on its own apart from hosting providers.

Re: You already have a Git server

#134

Earlier quoted context omitted.

> There's no server. There IS a server, it's the ssh daemon. That's the bit I had never thought about until now.

SSH is just a transport to get access to the repo information. The particular implementation does not matter (I think). Its configuration is orthogonal to git.

It's just a transport, and it needs a server.

Re: You already have a Git server

#135

Earlier quoted context omitted.

Git was always explicitly a decentralized, "peer to peer" version control system, as opposed to centralized ones like SVN, with nothing in the protocol itself that makes a distinction between a "server" and a "client". Using it in a centralized fashion is just a workflow that you choose to use (or, realistically, one that somebody else chose for you). Any clone of a repository can be a remote to any other clone, and…

It's a little more complex than that. Yes git can work in a peer-to-peer fashion, but the porcelain is definitely set up for a hub-and-spoke model, given how cloning a remote repo only gives you a partial copy of the remote history. There's other stuff too, like git submodules can't be configured to reference another branch on the local repository and then be cloned correctly, only another remote.

I'd say git submodules have such an awkward UX that should probably not be used except in very rare and organized cases. I've done it before but it has to be worth it.

But I get your larger point.

Re: You already have a Git server

#136

Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?

I never thought about it. If somebody had asked me, yeah. Of course it makes sense. But it's just one of those things where I haven't thought about possibility.

Re: You already have a Git server

#137

Earlier quoted context omitted.

Git was always explicitly a decentralized, "peer to peer" version control system, as opposed to centralized ones like SVN, with nothing in the protocol itself that makes a distinction between a "server" and a "client". Using it in a centralized fashion is just a workflow that you choose to use (or, realistically, one that somebody else chose for you). Any clone of a repository can be a remote to any other clone, and…

It's a little more complex than that. Yes git can work in a peer-to-peer fashion, but the porcelain is definitely set up for a hub-and-spoke model, given how cloning a remote repo only gives you a partial copy of the remote history. There's other stuff too, like git submodules can't be configured to reference another branch on the local repository and then be cloned correctly, only another remote.

> given how cloning a remote repo only gives you a partial copy of the remote history

When you clone you get the full remote history and all remote branches (by default). That’s painfully true when you have a repo with large binary blobs (and the reason git-lfs and others exist).

Re: You already have a Git server

#138

Earlier quoted context omitted.

I've been using git since 2007, this only dawned on me last year. Git is especially prone to the sort of confusion where all the experts you know use it in slightly different ways so the culture is to just wing it until you're your own unique kind of wizard who can't tie his shoes because he favors sandals anyhow.

> all the experts you know use it in slightly different ways What? Knowing that a git repo is just a folder is nowhere near "expert" level. That's basic knowledge, just like knowing that the commits are nodes of a DAG. Sadly, most git users have no idea how the tool works. It's a strange situation, it'd be like if a majority of drivers didn't know how to change gears.

The majority of drivers DON’T know how to change gears.

You are simultaneously saying that something is not expert level knowledge while acknowledging that most people don’t know it. Strange.

Re: You already have a Git server

#139

Earlier quoted context omitted.

Considering git is one of those things barely anyone knows how to actually use, yes

My theory is that git is just so easy to use without understanding it that you end up with lots of people using it without understanding it :)

It's not "so easy to use without understanding it", it's the opposite it has so much unnecessary complexity (on top of a brilliant simple idea btw), that once people learn how to do what they need, they stop trying to learn any more from the pile of weirdness that is git.

Decades from now, git will be looked back at in a similar but worse version of the way SQL often is -- a terrible interface over a wonderful idea.

Re: You already have a Git server

#140

I feel like something was lost along the way. git init —-bare will give you a git repo without a working set (just the contents typically in the .git directory). This allows you to create things like `foo.git` instead of `foo/.git`. “origin” is also just the default name for the cloned remote. It could be called anything, and you can have as many remotes as you’d like. You can even namespace where you push back to th…

git clone --mirror is another good one to know, it also makes a bare repository that is an exact clone (including all branches, tags, notes, etc) of a remote repo. Unlike a normal clone that is set up for local tracking branches of the remote. It doesn't include pull requests, when cloning from github, though.

> It doesn't include pull requests, when cloning from github, though.

Because GitHub pull requests are a proprietary, centralized, cloud-dependent reimplementation of `git request-pull`.

How the "free software" world slid head first into a proprietary cloud-based "open source" world still boils my blood. Congrats, Microsoft loves and owns it all, isn't that what what we always wanted?

Post reply on HN