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.
You already have a Git server
121–130 of 454 posts
Re: You already have a Git server
#122Maybe 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
Re: You already have a Git server
#123I 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…
Re: You already have a Git server
#124Maybe 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.
Re: You already have a Git server
#125Re: You already have a Git server
#126As 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…
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
#127Maybe I'm too old, but are there people that really didn't know that any ssh access is sufficient for using git?
Re: You already have a Git server
#128I 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
#129Earlier 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.
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
#130Maybe 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.