Live data from Hacker News

You already have a Git server

maurycyz.com

121–130 of 454 posts

Re: You already have a Git server

#121

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.

The Pro Git book is available online for free

https://git-scm.com/book/en/v2

Re: You already have a Git server

#122

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

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 :)

Re: You already have a Git server

#123

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 you can easily have a "git server" (ie. just another directory) in your local filesystem, which is a perfectly reasonable workflow in some cases.

Re: You already have a Git server

#124

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

I would be surprised if more than 10% of git users know that. Would be equally surprised if more than 20% of git users know how to use ssh. I think your age isn't the issue, but I suspect you're in a bubble.

The non-Windows bubble?

Re: You already have a Git server

#126
post #20

As a git user "not by choice" (my preference going for mercurial every single day), I never understood why git needs this distinction between bare/non-bare (or commit vs staging for that matter). Seems like yet another leaky abstraction/bad design choice.

A repo is as database containing a tree of commits. Then you got the concept of branch, which points to a specific commit. Then there's the special pointer HEAD which is the latest commit for the current worktree. When you checkout (now switch) a branch, HEAD is now the same as the branch (they point to the same commit). When you do operation like commit, reset, reset,... both the head and the branch are updated. So…

Mercurial has no distinction between a bare repo and a non-bare repo: any repo can have a working copy or not. You can check out a working copy with `hg update somerevision`, or get rid of it with `hg update null`.

You can push to a repo with a working copy, if you like; nothing will happen to that working copy unless you run `hg update`. Since you don’t need a working copy on the server’s repo, you never run `hg update` on it, and it’s effectively what git calls a bare repository.

Re: You already have a Git server

#127

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

Yes. I've been subject to claims that a single person can't start a project unless and until an official, centralized repo is setup for them. I've responded with "git init is all that is necessary to get started", but they wouldn't hear it.

Re: You already have a Git server

#128

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.

Re: You already have a Git server

#129

Earlier quoted context omitted.

I've never heard of... debian package builder? I don't care if it gets annoyed; if that's one of the biggest issues then that's a good sign for the method. Yes the commit won't be on the branch you want, but you'd get about the same issue if the two repos had a bare upstream. The branch diverges and you need to merge. It's a bit less ergonomic here but could be improved. Git could use branch following improvements in…

> Yes the commit won't be on the branch you want, but you'd get about the same issue if the two repos had a bare upstream. Not at all. The commit would have "landed" on the exact branch you thought it will. How it will be reconciled with a diverged remote branch is completely orthogonal and may not even be of concern in some use cases at all.

The situation is almost identical except you don't have a cute name for your new commit. Let's say you add a ref to your detached commit, perhaps local/foo. Then you're looking at a divergence between foo and local/foo. If you had a bare upstream it would be a divergence between origin/foo and foo. No real difference. And if you don't want to reconcile then you don't have to.

If git was a tiny bit smarter it could remember you were working on "foo" even after the ref changes.

Re: You already have a Git server

#130

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.

I like this comment. Over the years I've always found that whenever I see others using git, everyone uses it in different way and even for different purposes. This has left me really confused about what is the standard practice of Git exactly.
Post reply on HN