Live data from Hacker News

You already have a Git server

maurycyz.com

411–420 of 454 posts

Re: You already have a Git server

#411

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.

    > just like knowing that the commits are nodes of a DAG
Hello gatekeeping! I have used Git for more than 10 years. I could not explain all of the ins-and-outs of commits, especially that they are "nodes of a DAG". I do just fine, and Git is wonderful to me. Another related example: I would say that 90%+ of .NET and Java users don't intimately understand their virtual machine that runs their code. Hot take: That is fine in 2025; they are still very productive and add lots of value.

Re: You already have a Git server

#412

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

I read an article not long ago where students coming out of a web dev bootcamp were unable to make a hello world html file and open it in their browser. We’ve gone so far with elaborate environments and sets to make it easy to learn more advanced things, that many people never learn the very basics. I see this as a real problem.

With cors this can be awkward now.

Re: You already have a Git server

#413
post #392

Earlier quoted context omitted.

You're right, I got that part wrong, git actually fetches all of the remote commits (but not all of the refs, many things are missing, for instance notes). But a clone of your clone is not going to work the same way, since remote branches are not cloned by default, either. So it'll only have partial history. This is what I was thinking about.

Notes aren't refs.

Yes they are, they get put in /refs/notes?

    git fetch origin refs/notes/*:refs/notes/*
is the command you have to run to actually clone remote refs if you're making a working-copy clone?

Re: You already have a Git server

#414

Earlier quoted context omitted.

> 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.

> just like knowing that the commits are nodes of a DAG Hello gatekeeping! I have used Git for more than 10 years. I could not explain all of the ins-and-outs of commits, especially that they are "nodes of a DAG". I do just fine, and Git is wonderful to me. Another related example: I would say that 90%+ of .NET and Java users don't intimately understand their virtual machine that runs their code. Hot take: That is fi…

"Intimately understand the VM" is not the same as knowing what data structure you're using. It'd be comparable to not knowing the difference between an array and a linked list. Sure you may call it gatekeeping but likewise I may call your style willful ignorance of the basics of the tools you're using. Have you never used rebase or cherry-pick?

Re: You already have a Git server

#415

Earlier quoted context omitted.

> 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.

> It's a strange situation, it'd be like if a majority of drivers didn't know how to change gears. If you literally can't change gears then your choices are a) go nowhere (neutral), b) burn out your clutch (higher gears), or c) burn out your engine (1st gear). All are bad things. Even having an expert come along to put you in the correct gear once, twice, or even ten times won't improve things. If a programmer doesn'…

It's an analogy, there's no need to analyze it literally. And no, I've worked with some devs who don't understand git (thankfully I don't anymore) and it was quite a bit more than "five times" they got stuck or messed up the repo on the remote in an annoying way. Sure, if you regularly write code using a bunch of evals or gotos "nothing bad will happen" but it's a very suboptimal way of doing things.

Re: You already have a Git server

#416

Earlier quoted context omitted.

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?

wouldn't it be cool to have an open source (maybe even p2p/federated) version of GitHub?

Re: You already have a Git server

#417
So my friend and I were trying to learn some coding together. We had our laptops on the same wifi and I wanted us to use git without depending on GitHub, but I was completely stumped as to how to actually connect us together. I don't want us to setup SSH servers on each other's laptops, giving each other full access to our computers, and sending patches to each other across the living room seems overkill when we're just sitting around hacking away on our keyboards wanting to share what we've come up with every few minutes or so. I still have no idea how I would solve this. Maybe I'd just try coding with a syncthing directory shared between us, but then that's totally giving up on git

Re: You already have a Git server

#418

Earlier quoted context omitted.

My way used to be in the past, put bare repos on Dropbox, clone the bare repo to a real path. Done. 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 `…

That doesn't work -- I've tried it. I mean, it works fine for a few days or weeks, but then it gets corrupted. Doesn't matter if you use Dropbox, Google Drive, OneDrive, whatever. It's apparently something to do with the many hundreds of file operations git does in a basic operation, and somehow none of the sync implementations can quite handle it all 100.0000% correctly. I'm personally mystified as to why not, but c…

Among other reasons, the sync engines of these cloud stores all have "conflict detection" algorithms when multiple machines touch the same files, and while a bare repo avoids conflicts in the worktree by not having a worktree, there are still a lot of files that get touched in every git push: the refs, some of the pack files, etc.

When it is a file conflict the sync engines will often drop multiple copies with names like "file (1)" and "file (2)" and so forth. It's sometimes possible to surgically fix a git repo in that state by figuring out which files need to be "file" or "file (1)" or "file (2)" or whatever, but it is not fun.

In theory, a loose objects-only bare repo with `git gc` disabled is more append-only and might be useful in file sync engines like that, but in practice a loose-objects-only bare repo with no `git gc` is not a great experience and certainly not recommended. It's probably better to use something like `git bundle` files in a sync engine context to avoid conflicts. I wonder if anyone has built a useful automation for that.

Re: You already have a Git server

#419
post #3

Interesting. I am just trying to decide between self-hosting Forgejo and other options for hosting Git in own private network.

One of my favorite tools available for Linux is called gitolite. It's in the Debian repo. 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 upd…

gitolite is great. It's simple and extremely lightweight.

Re: You already have a Git server

#420

So my friend and I were trying to learn some coding together. We had our laptops on the same wifi and I wanted us to use git without depending on GitHub, but I was completely stumped as to how to actually connect us together. I don't want us to setup SSH servers on each other's laptops, giving each other full access to our computers, and sending patches to each other across the living room seems overkill when we're j…

Have you tried git daemon? https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon
Post reply on HN