You already have a git server
119 points by runxiyu
119 points by runxiyu
Uhm, generally using checked-out repos for pushing is... quite bad and easily leaves the repo in an inconsistent state. Bare repos aren't that hard...
It also seems to tell people that Dumb HTTP is a reasonable Git HTTP transport... sure, it's ridiculously simple, but also extremely poor in performance.
Good is the enemy of good enough.
People should feel empowered to start with what they have first.
Or you just do git init --bare and feel good.
I made a script in order to feel even better. Combines bare git repositories with worktrees.
project/
git/
trees/
master/
topic/
Working with branches this way is so nice.
I've been trying to figure out directory layouts with trees, this is perfect, thank you so much!
(I never used them much but am starting to incorporate them into my workflow)
I even sent some patches for a git url-parse command. I wanted to use it in this script to set the repository name automatically from the remote URL, as well as set better remote names like github.com instead of origin. I don't know if they accepted the patch... Kinda forgot about it.
It's excellent that it's low cost to get an even better setup. Low cost, but not as low as "you already are done."
easily leaves the repo in an inconsistent state.
How so? I believe the idea that "it gets less conflicts" is based on people manually checking out different branches on the server. Or am I missing something?
When the HEAD is moved by a push, it will detach itself from the index and working copy.
If you switch between branches in the working copy, then remote users will see different default branches at different times.
There are probably other gotchas…
For 99.9% of the cases it's pretty good. 100% if you're talking about projects managed by a single person.
I didn’t even know you could do this on a checked-out repo. I use a bare repo on my server as a secondary remote for client projects that I will push to more frequently during the build-up to a milestone or a PR. Aside from making a backup, that gives me a way to rebase & force push if I want to tidy things up before pushing to the client’s (clarification: customer’s) remote. Often I will of course work in a branch, but sometimes depending on scope it’s just mainline dev and then I’ll want to clean up main.
A long time ago I tried doing this and remember getting a very loud warning or error. Led to me learning all about bare repos.
I once gave someone read-only access to my code over ssh. Words can't express how deeply uncomfortable he was that it wasn't github, even though my instruction worked for him within seconds and was so uncomplicated that he didn't need to give me a public key
You don't even need a "server": you can git clone an existing directory containing a repo. That's occasionally useful if you want multiple copies (although a single repo can also have multiple "work trees"); but it can also be useful if you've got remote drives/mounts.
You can also push/pull changes over SSH, without having to set up a dedicated remote; e.g. git fetch ssh://myuser@somehost:/home/myuser/myrepo master:refs/heads/stufffromsomehost
People were using git well before sites like Gitorious, Gitlab, etc. came along; and not necessarily via mailing lists (which is a whole other thread). Whilst such sites do provide a convenient point for centralisation/coordination of a project, i.e. a "blessed" copy which every clone can push to & pull from; sometimes that's more effort than necessary for tasks like "grab changes ABC from XYZ".
I knew many people only ever used git through github, but I didn't know so many of them didn't realize you could clone a directory or use ssh
Interesting PSA but setting up Gitea using Docker is quite straightforward and a much better experience in the long term.
I've had a Gitea instance on my personal VPS for several years and after initial setup I've barely had any maintenance on it beyond automated updates.
I had the opposite experience, so cumbersome, and it all fell apart the moment someone wanted to contribute a patch.
Fwiw my Gitea instance is private & single user so I have no idea how the experience is when having multiple users. It's very possible it sucks at that.
Anything public where I want to get contributions from others I use GitHub :)
No way. A whole container, with its everything, requiring docker plus a ton of other configurations, secrets and other local state. Nothing of this is free. You need to keep track of all those in your head or somewhere else. Sure it has more features, but they don't come with considerable costs.
On linux docker containers aren't free but they're relatively cheap (modulo disk space).
The annoying thing is more that it's a but of a thing to set up and it's in its own universe so you're not just locking to journalctl and the like.
In a way snaps on linux are probably more straightforward for people managing a linux server cuz it'll at least pipe into the systemd tooling.
Having said all that I kinda loath tools that are like "use docker to get this to run". I thought the point of stuff like Go and Python was not having to do that kind of thing!
‘Cheap’ isn’t just about low CPU overhead. It’s also about management overhead and attack surface.
Yeah I agree about the analysis being holistic, and it's not pure wins. I can't comment much on attack surface but hard to argue that it doesn't generate "more" potential issues to have more things running.
As a person who dislikes Docker but spent too much time finding excuses not to dive into it... I've found the management overhead stuff at least to be somewhat resolvable
The alternatives for some software have their own issues: running off of your OS package manager if you're a Debian-like means you can't really upgrade the software by itself (or rollback if you find issues), using language managers have their own set of things.
The "docker image tag is the one thing to manage and you are decoupled from your OS package manager" offering does make management easier in some sense. Sometimes at least.
If you are using the issue tracker, etc., then definitely, because it's doing more.
But if it's just about push/pull, in my opinion, nope. I had some fun playing with gitweb two weeks ago. In my opinion, raw git is only scary because it's uncommon, but setting it up once you know how is a breeze and the result is much simpler than anything else.
And collaboration is simple! We're just not used to it. You don't need to go to a full complex email workflow- git format-patch/git am and you can send the stuff via whatever communication channel you have. You don't have to set up mutt, local mail, anything. Kernel hackers have complex setups because it's faster and more automated, but patch-based collaboration can be simpler, and rely on tools you already have.
It depends on what you're doing, even when working on repos that are hosted on a forge, I find it's sometimes nicer to move the state of a WIP branch directly from one machine to another rather than taking the round trip through the forge.
Yeah, I do this with syncthing, every once it a while it barfs on something, but git clean can deal with it along with checkout, a little find exec rm can fix issues in .git
This happened pretty rarely though
I’ve bounced off gitea the few times I’ve tried it. I was expecting it to be essentially equivalent to gogs but it’s a tier more complex. I do have a private gogs instance, the main feature I use it for is mirroring GitHub repos. I don’t get any other value out of it that bare git repositories didn’t already give me.
I use Forgejo for basically the same usecase. I use it over a bare git repo because I want issues/comments. I have a repo called 'me' that holds my life. I build issues there instead of a TODO list. I throw my notes and comments there instead of Obsidian/notes/etc.
It works great. has been very reliable. Works well on mobile, etc.
Additionally to ssh and file based like commented, you can run the built in git daemon too.
If you tell it to --listen only on an address that's on your private, encrypted, virtual network, then that's another way to make it "secure" without creating a bunch of accounts for ssh.
There may be some other options you need to turn on; I haven't messed with it in a while. Maybe receive-pack. https://git-scm.com/docs/git-daemon