For my private, personal Git server, I recently moved from Gitea to Soft Serve [1], and have enjoyed how light and fast it is. I have it hooked up via Tailscale (using TS_DEST_IP to forward traffic [2]), so it has its own IP on the network and I don't have services fighting for port 22.

TUI tools over SSH definitely aren't for everyone, but if that's your style and you want a place to dump all your non-public projects, it's a great choice.

Most non-private stuff goes on Sourcehut, and anyone can contribute via email (i.e. without any account) assuming they don't mind going through the arcana required to set up git-send-email.

[1] https://github.com/charmbracelet/soft-serve

[2] https://hub.docker.com/r/tailscale/tailscale

▲

Fluorescence 4 days ago | parent | next [-]

What did you not find fast about gitea/forgejo?

I've really enjoyed using them but I guess I don't do much with the web interface.

> TS_DEST_IP

So you run tailscale in your git server container so it gets a unique tailnet ip which won't create a conflict because you don't need to ssh into the container?

I might give that a go. I run tailscale on my host and use a custom port for git which you set once in your ~/.ssh/config for host/key config on client machines and then don't need to refer to it repo uris.

TBH, I think it's tailscale I'd like a light/fast alternative to! I have growing concerns because I often find it inexplicably consuming a lot of CPU, pointlessly spamming syslog (years old github issues without response) or otherwise getting fucked up.

	▲	abound 4 days ago \| parent [-]
		> What did you not find fast about gitea/forgejo? They're plenty fast, but it's hard to match the speed of terminal tools if you're used to working that way. With Soft Serve, I'm maybe 10 keystrokes and two seconds away from whatever I want to access from a blank desktop. Even a really performant web application is always going to be a bit slower than that. Normally that kind of micro-optimization isn't all that useful, but it's great for flitting back and forth between a bunch of projects without losing your place. > So you run tailscale in your git server container so it gets a unique tailnet ip which won't create a conflict because you don't need to ssh into the container? Pretty much. It's a separate container in the same pod, and shows up as its own device on the tailnet. I can still `kubectl exec` or port forward or whatever if I need to access Soft Serve directly, but practically I never do that. > TBH, I think it's tailscale I'd like a light/fast alternative to! I've never noticed Tailscale's performance on any clients, it "just works" in my experience. I'm running self-hosted Headscale, but wouldn't expect it to be all that different performance-wise.

▲

account42 4 days ago | parent | prev | next [-]

What do you even need a git server for if its just for private projects - you can have a remote repo accessible via ssh without any other software needed.

	▲	abound 4 days ago \| parent [-]
		Easy backups, especially for repos that use Git LFS. It's also nice to have a simple UI for browsing repos and project history. Soft Serve doesn't have built in CI/CD, but I plan on bolting on a lightweight solution there. I have hundreds of random tools and half-finished projects, having them all accessible and searchable from a single location is convenient.

▲

navigate8310 4 days ago | parent | prev [-]

When people say, they can contribute via email, does this mean they'll zip altered files and mail to the repo owner?

	▲	skydhash 4 days ago \| parent \| next [-]
		Git has a set of commands that can either provide ready to be sent email messages as files (if you have a proper client, not the web ones), or send the formatted email for you. Most good clients have a way to directly pipe messages to the shell, so you can execute git directly from there to apply the change. Quite streamlined once you've got everything setup (not that difficult) [0]. But it does requires people to be disciplined with their changes (no wip commits). This may require learning about the flags for `git rebase` and `git commit`. [0]: https://git-send-email.io/
	▲	goku12 3 days ago \| parent \| prev \| next [-]
		No. You'd send 'patches' via email. Each patch roughly corresponds to a commit. These are diffs + commit metadata that are directly formatted as email messages. A single submission of multiple commits will be made of multiple threaded email messages. The maintainer then 'applies' the received patches to their repo to recreate the commits from the contributor. I know that this sounds complicated, but it's quite streamlined in git. You don't have to do all that manually. There is one more way to contribute by email. And they are... surprise! Pull requests! You can send pull requests to the maintainer via email, as long as your own modified clone repo is hosted and accessible online somewhere. It doesn't have to be on the same server (unlike github forks). This is done using the `git request-pull` command.
	▲	1718627440 4 days ago \| parent \| prev [-]
		Wouldn't they use git format-patch?