Hard to justify using SSH for Git. Principle of least power and all that
https://gitolite.com/gitolite/
If you think the bare bones example is interesting and want something simple just for you or a small group of people, this is one step up. There's no web interface. The admin is a git repository that stores ssh public keys and a config file that defines repo names with an ACL. When you push, it updates the authorization and inits new repositories that you name.
I put everything in repos at home and a have multiple systems (because of VMs) so this cleaned things up for me considerably.
TIL about the update options for checked out branch. In practise though usually you want just the .git "bare" folder on server
Tip: create a `git` user on the server and set its shell to `git-shell`. E.g.:
sudo useradd -m -g git -d /home/git -s /usr/bin/git-shell git
Then, when you need to create a new repository you run:
sudo -u git git init --bare --initial-branch=main /home/git/myrepo.git
git clone git@myserver:myrepo.git
git remote add myserver git@myserver:myrepo.git
git push -u myserver main
I think that initializing a bare repository avoids the workarounds for pushing to a currently checked out branch.
However, this setup doesn't work with git-lfs (large file support). Or, at least I haven't been able to get it working.
PS: Even though git-shell is very restricted you can still put shell commands in ~/git-shell-commands
This is the usecase mentioned in the article and it wouldn't work with a bare repo. But if the server your SSH'ing to is just a central point to sync code across machines, then you're right: multiple hoops mentioned in the article are solved by having the central repo bare.
git init
git commit -am Initial\ commit
git clone . ssh://server/path/to/repo
Bitkeeper and a few other contemporaries would let you just push to a remote path that doesn’t exist yet and it’d create it. Maybe git added this since then, but at the time it seemed like a huge omission to me.
the vastly superior way is 'git bare' which is a first class supported command without hacky settings.
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 if a remote node tries to update the local node via a push on its end, that would mess up the local worktree. So you create a bare repo instead which can't contain a local worktree.
Note: A worktree is computed from the initial commit to the commit currently identified by HEAD by following the parent information on each commit.
The staging area is like a stored snapshot of what you would like to commit. You can always create patch between HEAD and the worktree, edit it, and then save the patch as the commit, then apply the leftover to the worktree. The staging just make that easier. It's a WIP patch for the next commit.
Actually, HEAD now points to that branch, which in turn points to the commit. It's a different state than when HEAD points directly to the same commit (called "detached HEAD" in Git's terminology) where this issue doesn't happen as you're not on a branch at all. It's a subtle, but important distinction when trying to understand what happens under the hood there.
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.
Case one: WiP on a branch, code is pretty stable, but I want to do some experiments which will likely be deleted. I stage everything and then make (unstaged) changes which I can then undo with two keystrokes.
Case two: I'm reviewing a complex PR, so I first merge it with --no-commit, then unstage everything and then stage chunks (or even individual lines) I have already reviewed.
Case three: I was coding in the state of flow and now I have a lot of changes I want to commit, but I want to separate them into several atomic commits. I stage the first batch of changes, commit, then stage another, commit, etc.
There are probably more, but these three alone are worth having the staging area.
The immediate response from many git users when confronted to alternative VCSes is "well, it doesn't have a staging area, so it's obviously inferior" instead of going with "let's see how differently they approach this problem, and perhaps I will like it/git isn't all perfect after all".
If you want a public facing "read only" ui to public repositories you can use cgit (https://git.zx2c4.com/cgit/about/) to expose them. That will enable others to git clone without using ssh.
I keep my private repositories private and expose a few public ones using cgit.
Why is GitHub popular? its not because people are "dumb" as others think.
Its because GitHub "Just Works".
You don't need obscure tribal knowledge like seba_dos1 suggests [0] or this comment https://news.ycombinator.com/item?id=45711294
The official Git documentation for example has its own documentation that I failed to get work. (it is vastly different from what OP is suggesting)
The problem with software development is that not knowing such "tribal knowledge" is considered incompetence.
People don't need to deal with obscure error messages which is why they choose GitHub & why Github won.
Like the adge goes, "Technology is best when it is invisible"
[0] https://news.ycombinator.com/item?id=45711236
[1] https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-...
Still, I like the online browser, and pr workflow.
However would NEVER trust Github since the MS acquisition. codeberg and https://forgejo.org are perfectly sound FOSS alternative to GitHub and GigLabs nowdays.
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 general.
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.
[0] Source: pulled out of my arse.
Good job, now you can't add it nor remove it, without manually removing it in .git folder.
The knowledge is neither obscure nor tribal, it is public and accessible. And likely already on your system, in the form of man-pages shipped with your git binaries.
> The problem with software development is that not knowing such "tribal knowledge" is considered incompetence.
Consequently.
For normal users. Having this tribal knowledge is basically what makes developer and it’s their job to make technology invisible for others. Someone has to be behind the curtain.
IPv6 still doesn't work with GitHub: https://doesgithubhaveipv6yet.com/
Not because it's hard or obscure to put git on your server.
I think your comment shows some confusion that it's either the result or cause of some negative experiences.
Starting with GitHub. The primary reason it "just works" is because GitHub, like any SaaS offering, is taking care of basic things like managing servers, authorization, access control, etc.
Obviously, if you have to setup your own ssh server, things won't be as streamlined as clicking a button.
But that's obviously not the point of this post.
The point is that the work you need to do to setup a Git server is way less than you might expect because you already have most of the things already set, and the ones that aren't are actually low-hanging fruit.
This should not come as a surprise. Git was designed as a distributed version control system. Being able to easily setup a stand-alone repository was a design goal. This blog post covers providing access through ssh, but you can also create repositories in any mount point of your file system, including in USB pens.
And, yes, "it just works".
> The official Git documentation for example has its own documentation that I failed to get work. (it is vastly different from what OP is suggesting)
I'm sorry, the inability to go through the how-to guide that you cited has nothing to do with Git. The guide only does three things: create a user account, setup ssh access to that account, and create a Git repository. If you fail to create a user account and setup ssh, your problems are not related to Git. If you created a user account and successfully setup ssh access, all that is missing is checking out the repo/adding a remote repo. If you struggle with this step, your issues are not related to Git.
What are we supposed to do ... throw our hands up because GitHub won?
I'll be down voted, but I'll say it. If you hold that attitude and you don't learn the fundamentals, if you don't understand your tools, you're a bad developer and a poor craftsman. You're not someone I would hire or work with.
Git's difficulty is NOT intrinsic; it could be a much better tool if Torvalds were better at UX. In short, I don't blame people who don't want to "learn git". They shouldn't have to learn it anymore than one learns to use a browser or Google docs.
You're likely using a VCS, which is likely git (or jj, hg, fossil, tfs, etc).
Therefore, you should know how to use whatever you're using. It shouldn't be "invisible" to you.
> Its because GitHub "Just Works".
Git also "just works". GitHub simply offers a higher level of abstraction, a graphical UI, and some value-add features on top of Git. How much better all this really is arguable. I would say that it's disastrous that most developers rely on a centralized service to use a distributed version control system. Nevermind the fact that the service is the single largest repository of open source software, owned and controlled by a giant corporation which has historically been hostile to OSS.
GitHub "won" because it came around at the right time, had "Git" in its name—which has been a perpetual cause of confusion w.r.t. its relation with Git—, and boosted by the success of Git itself largely due to the cult of personality around Linus Torvalds. Not because Git was technically superior, or because GitHub "just works".
> You don't need obscure tribal knowledge
As others have said, a bare repository is certainly not "tribal knowledge". Not anymore than knowing how to use basic Git features.
> Like the adge goes, "Technology is best when it is invisible"
Eh, all technology is an abstraction layer built on top of other technology. Whether it's "invisible" or not depends on the user, and their comfort level. I would argue that all abstractions also make users "dumber" when it comes to using the layers they abstract. Which is why people who only rely on GitHub lose the ability, or never learn, to use Git properly.
Unfortunately (though expected), ever since Microsoft took over this has devolved into GitHub "sometimes works".
At the very least, a huge part of the intent of Git's very design was decentralization; though as is the case with many good tools, people don't use them as they are designed.
Going further, simply because "deeply centralized Git" is very popular, does not AT ALL determine that "this is the better way to do things." Please don't frame it as if "popular equals ideal."
Managing code is one of the cornerstones of software engineering. It would be like refusing to learn how to use a screwdriver because someone really just wants to hammer things together.
The great thing about $your-favorite-scm is that it transcends language or framework choices and is fungible for early any project, even outside of software. I’m surprised it isn’t part of more professional tools.
I really preferred the idea of just paying for what I used -- rather than being on a "freemium" model with GitHub.
But -- as many things with Google -- it was shutdown. Probably because most other people do prefer the freemium model.
I wonder if this kind of thing will come back in style someday, or if we are stuck with freemium/pro "tiers" for everything.
It'd be great if there was more specific support. But in practice? No problems so far.
git clone ssh://username@hostname/path/to/repo
git clone username@hostname:path/to/repo
git clone hostname:path/to/repo
git init —-bare
“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 the same remotes by changing fetch and push paths. At one company it was common to push back to `$user/$feature` to avoid polluting the root namespace with personal branches. It was also common to have `backup/$user` for pushing having a backup of an entire local repo.
I often add a hostname namespace when I’m working from multiple hosts and then push between them directly to another instead of going back to a central server.
For a small static site repo that has documents and server config, I have a remote like:
[remote “my-server”]
url = ssh+git://…/deploy/path.git
fetch = +refs/heads/*:refs/remotes/my-server
push = +refs/heads/*:refs/remotes/my-laptop
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.
But I get your larger point.
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).
You may be thinking of the optional -depth switch, which allows you to create shallow clones that don't have the full history. If you don't include that, you'll get the full history when cloning.
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.
git clone --mirror <remote>
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?
I got pwned this way before (by a pentester fortunately). I had to configure Apache to block the .git directory.
I usually throw `etc` and `log` directories at the top level as well and out my server config in etc, and have a gitignite rule to ignore everything in logs, but it’s there and ready for painless deployment.
Since the web root is already a sub directory, more sensitive things can go into the same repo without worrying about exposing them.
So many features and concepts; it's easy to think you understand the basics, but you need to dig deep into it's origin and rationale to begin to grasp the way of thinking it is built around.
And the API surface area is much larger than one would think, like an iceberg
So I find it really weirdly low level in a way. Probably what is needed is is a higher-level CLI to use it in the most sensible, default way, because certainly the mental model most people use it with is inadequate.
It's mostly probably fine if that's the thing most of everybody wants to use and it works well; but also it's very unwise to forget that the point was NEVER to have a deeply centralized thing -- and that idea is BUILT into the very structure of all of it.
thyristan•2h ago
liveoneggs•2h ago
halJordan•2h ago
blueflow•2h ago
Imagine what the equivalent argumentation for a lawyer or nurse would be. Those rules ought to apply for engineers, too.
loloquwowndueo•2h ago
liveoneggs•2h ago
Dylan16807•1h ago
albert_e•2h ago
jiggawatts•2h ago
watwut•2h ago
These guys won.
bfkwlfkjf•2h ago
Even someone who knows that git isn't GitHub might not be aware that ssh is enough to use git remotely. That's actually the case for me! I'm a HUGE fan of git, I mildly dislike GitHub, and I never knew that ssh was enough to push to a remote repo. Like, how does it even work, I don't need a server? I suspect this is due to my poor understanding of ssh, not my poor understand of git.
porridgeraisin•2h ago
You do, an SSH server needs to be running on the remote if you want to ssh into it, using your ssh client - the `ssh` command on your laptop. It's just not a http server is all.
You start that server using the `sshd` [systemd] service. On VPSs it's enabled by default.
Git supports both http and ssh as the "transport method". So, you can use either. Browsers OTOH only support http.
bfkwlfkjf•1h ago
Edit: hey this is really exciting. For a long time one of the reasons I've loved git (not GitHub) is the elegance of being a piece of software which is decentralized and actually works well. But I'd never actually used the decentralized aspect of it, I've always had a local repo and then defaulted to use GitHub, bitbucket or whatever instead, because I always thought I'd need to install some "git daemon" in order to achieve this and I couldn't be bothered. But now, this is so much more powerful. Linus Torvalds best programmer alive, change my mind.
Dylan16807•1h ago
And most things are files.
liveoneggs•2h ago
Read https://git-scm.com/docs/git-init#Documentation/git-init.txt...
Anyway it sounds like you have a lot of holes in your git-knowledge and should read some man pages
bfkwlfkjf•1h ago
liveoneggs•18m ago
https://git-scm.com/book/ms/v2/Git-on-the-Server-The-Protoco...
skydhash•2h ago
From the git-fetch(1) manual page:
> Git supports ssh, git, http, and https protocols (in addition, ftp and ftps can be used for fetching, but this is inefficient and deprecated; do not use them).
You only need access to the other node repo information. There's no server. You can also use a simple path and store the other repo on drive.
bfkwlfkjf•1h ago
There IS a server, it's the ssh daemon. That's the bit I had never thought about until now.
skydhash•1h ago
bfkwlfkjf•58m ago
Joeboy•1h ago
bfkwlfkjf•1h ago
setopt•2h ago
devsda•2h ago
Now, if it is a growing misconception among cs students or anyone doing software development or operations, that's a cause for concern.
littlecranky67•2h ago
mrweasel•1h ago
Clip from the interview: https://www.youtube.com/shorts/0wLidyXzFk8
ruguo•1h ago
brucehoult•2h ago
ryandv•2h ago
https://www.theverge.com/22684730/students-file-folder-direc...
liveoneggs•1h ago
politelemon•2h ago
superdisk•1h ago
kace91•2h ago
But more importantly, I’m not sure why I would want to deploy something by pushing changes to the server. In my mental model the repo contains the SOT, and whatever’s running on the server is ephemeral, so I don’t want to mix those two things.
I guess it’s more comfortable than scp-ing individual files for a hotfix, but how does this beat pushing to the SOT, sshing into the server and pulling changes from there?
skydhash•1h ago
t_mahmood•2h ago
That way, I
1. didn't have to worry about sync conflicts. Once complete, just push to origin 2. had my code backed up outside my computer
I can't exactly remember, if it saves space. I assumed it does, but not sure anymore. But I feel it was quite reliable.
I gave that way up with GitHub. But thinking of migrating to `Codeberg`
With `tailscale`, I feel we have so much options now, instead of putting our personal computer out on the Internet.
candiddevmike•2h ago
yule•1h ago
skydhash•1h ago
CGamesPlay•1h ago
I did a quick search for "post-receive hook ci" and found this one: https://gist.github.com/nonbeing/f3441c96d8577a734fa240039b7...
bluedino•1h ago
seba_dos1•1h ago
BoiledCabbage•54m ago
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.
seba_dos1•42m ago
I don't think git would end up this popular if it didn't allow to be used in a basic way by just memorizing a few commands without having to understand its repository model (however simple) well.
isodev•1h ago
tuwtuwtuwtuw•1h ago
I think your age isn't the issue, but I suspect you're in a bubble.
kleiba•1h ago
dtgriscom•1h ago
__MatrixMan__•1h ago
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.
skydhash•1h ago
https://git-scm.com/book/en/v2
tianqi•1h ago
haskellshill•59m ago
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.
rco8786•55m ago
You are simultaneously saying that something is not expert level knowledge while acknowledging that most people don’t know it. Strange.
singpolyma3•47m ago
seba_dos1•31m ago
I'm not sure that's true, unless you only take certain parts of the world into consideration.
__MatrixMan__•14m ago
thwarted•1h ago
fingerlocks•21m ago
victorbjorklund•57m ago