Remix.run Logo
I_am_tiberius 4 hours ago

Codeberg is only for FOSS projects. Is there some good European hosting provider for git? I really don't want to self host git.

dethos 20 minutes ago | parent | next [-]

One of the other comments mentions https://codefloe.com. I haven't tested and haven't yet checked their background, but they seem to allow private repositories.

petcat 3 hours ago | parent | prev | next [-]

devault made sourcehut which I think is hosted in the netherlands

https://sr.ht

I tried it once, it's very opinionated and may not be suitable for what a lot of people think of when they're coming from something like Github. The required old-school patch-by-mail thing is a blocker for a lot of people.

AndrewDucker 3 hours ago | parent | prev | next [-]

I am boggled by the number of people who see "I really don't want to X" and then reply with "Here's how to easily do X!"

icy 16 minutes ago | parent | prev | next [-]

https://tangled.org :) We're hosted in the EU.

layer8 an hour ago | parent | prev | next [-]

Take a look at https://www.lcube-webhosting.de/en/svn-hosting-repositoryonl..., starts at 2.90 Euro. No personal experience, but the fact that they are still including SVN support tells you how long-established they are.

Google reviews: https://www.google.com/search?q=lcube&ludocid=91685905651961...

rapnie 4 hours ago | parent | prev | next [-]

Regarding Forgejo [0] there are a number of other open providers listed on the delightful forgejo [1] curated list. In addition there is a Professional services repository [2] where services are listed in the issue tracker.

[0] https://forgejo.org

[1] https://delightful.coding.social/delightful-forgejo/#public-...

[2] https://codeberg.org/forgejo/professional-services/issues

p2detar 3 hours ago | parent | prev | next [-]

I self-host Forgejo on a Docker container. Thinking about it, this is actually the right way to go.

If you got public projects, then something like Codeberg is in fact the place to go. If you got private projects, why push to someone's cloud-hosted git service at all? Push to your own service like Forgejo and sync backups to a local hard-drive or even online using rclone.

nottorp 2 hours ago | parent [-]

Because I don't mind paying github $4 or $7 and not worry about the admin burden.

Of course, this goes for simpler setups where you only use the git hosting part. Because to switch providers you only have to change the remote and push.

If you got yourself dependent on their other pipelines, it's more complicated.

christophilus 3 hours ago | parent | prev | next [-]

I think Sourcehut is EU based now.

thijsw 3 hours ago | parent | prev | next [-]

Yes, check out https://www.gitlabhost.com/ It is based in the Netherlands

roelschroeven 2 hours ago | parent | next [-]

AFAICS the cheapest option is 250€/month. That seems geared towards businesses, not individuals.

I_am_tiberius 2 hours ago | parent | prev [-]

Crazy expensive for small projects

fanatic2pope 2 hours ago | parent | prev | next [-]

For just the basics, self-hosting of git can be pretty easy. I use gitolite on a VPS.

https://gitolite.com/gitolite/

teekert 3 hours ago | parent | prev | next [-]

Uhm, is it? I have some small repos there, which are private and for my company (ie the website). I didn't encounter any warnings?

Edit, it says indeed (right in your face on the front page):

Codeberg is a non-profit, community-led effort that provides services to free and open-source projects, such as Git hosting.

I just click... click opened a repo and set it as remote and boom. Never thought anything of it... Perhaps I'm... Tolerated for the time being?

PurpleRamen 2 hours ago | parent [-]

You are just a glitch in their system. They won't check the content of private repos, and they probably also do not check if there is free software hosted at the same account, so you might have found the hole in their good will.

But their limit seems around 100 MB storage-usage, so I guess it's within their abilities to tolerate some glitches.

teekert 44 minutes ago | parent [-]

Ah ok, well, save for some drafts I wouldn't mind opening the repo which is just a Hugo system intended for a public website anyway. But good to know. Perhaps I will self-host that forgejo instance then :)

olavgg 3 hours ago | parent | prev | next [-]

Gitea is one of the easiest projects to to self-host. And to do regular upgrades, you only need to update one file. It has been a joy to self-host for many years now.

Jnr 3 hours ago | parent [-]

I don't even update one file. I run it in docker with daily automatic container updates and it has been working fine without issues for years.

lynx97 4 hours ago | parent | prev | next [-]

Git is extremely easy to "self host". What makes things complicated are the web interfaces around code hosting, and all their supposedly important features. These days, Prs, issues, forums, wikis and all that seem to be synonymous with "git", which is pretty weird.

kace91 3 hours ago | parent | next [-]

What do you mean by supposedly?

The PR model is pretty much universal for a reason. I get why it is considered out of scope for core git, but it is by no means a weird fixation people have.

lynx97 3 hours ago | parent [-]

Just send me an email with your branches URL, and I will pull from it. Thats pretty much what a Pull Request is.

kace91 3 hours ago | parent | next [-]

>Thats pretty much what a Pull Request is.

Then you have to use email for the review conversation, make the discussion easily available to everyone involved and future devs, track manually which comment refers to which line of the diff due to lack of overlaying, manually ping to warn of updates, rely on manual quoting, no direct information on whether the CI pipeline succeeded...

To me that feels like writing code using only sed. It is possible, but it removes or makes convoluted an absurd degree of regular work.

Jnr 3 hours ago | parent | prev | next [-]

You are correct, but integration with CI/CD and other services as a part of pull-request process in a modern platform is very convenient. I would not go back to e-mail. Especially since I can self host the whole platform like Gitea.

hvb2 3 hours ago | parent | prev [-]

And the discussion about that PR goes in an email chain too?

You can pull, but having the back and forth documented along with the code is not a nice to have imho

spiffyk 3 hours ago | parent | next [-]

Not that it fits everyone, but that is basically how the Linux kernel is being developed.

cyanydeez 3 hours ago | parent | prev | next [-]

Guys, guys, I'm just vibe coding here; just give me your credentials and mothers maiden name and I'll get it myself.

lynx97 3 hours ago | parent | prev [-]

If it is not in git log, a few months down the drain, nobody will read the PR discussion anyway.

rapnie 3 hours ago | parent | prev | next [-]

Because there isn't really a good name. In FOSS circles the name "code forge" is often used, and then OP might say "git-based code forge" instead. But both Github and Gitlab don't consider themself (and aren't) code forges. The term doesn't carry the load of the product positioning. So "hosting provider for git" is a pretty good description imho.

ptsneves 3 hours ago | parent | prev [-]

Which is ironic because PR is definitely alien to git. There is no such git concept as a PR, nor git pr command.

Coming from a pure git workflow in mailing lists where branches, and commits(and associated diff and git am metadata) are the unit of work, I struggled to adapt into the PR concept in the beginning.

I liked to work with gerrit, where the unit of the review is the commit. This also ensured a nice little history and curation of the change set. The commit in github is not even in the main tab of the PR. It is like it is a second thought. Even in the review, reviewing by commit is awkward and discouraged.

_flux 3 hours ago | parent [-]

There are the commands git request-pull and git send-email to work with that workflow, though.

cyanydeez 3 hours ago | parent | prev | next [-]

gitlab ce is easy to host.

sam_lowry_ 3 hours ago | parent | prev [-]

Here's a step-by step guide:

Change directory to your local git repository that you want to share with friends and colleagues and do a bare clone git clone --bare . /tmp/repo.git You just created a copy of the .git folder without all the checked out files.

Upload /tmp/repo.git to your linux server over ssh. Don't have one? Just order a tiny cloud server from Hetzner or another European provider. You can place your git repository anywhere, but the best way is to put it in a separate folder, e.g. /var/git. The command would look like with scp -r /tmp/repo.git me@server:/var/git/.

To share the repository with others, create a group, e.g. groupadd --users me git You will be able to add more users to the group with groupmod.

Your git repository is now writable only by me. To make it writable by the git group, you have to change the group on all files in the repository to git with chgrp -R git /var/repo.git and enable the group write bit on them with chmod -R g+w /var/repo.git.

This fixes the shared access for existing files. For new files, we have to make sure the group write bit is always on by changing UMASK from 022 to 002 in /etc/login.defs.

There is one more trick. For now on, all new files and folders in /var/git will be created with the user's primary group. We could change users to have git as the primary group.

But we can also force all new files and folders to be created with the parent folder's group and not user primary group. For that, set the group sticky bit on all folders in /var/git with find /var/git -type d -exec chmod g+s \{\} +

You are done.

Want to host your git repository online? Install caddy and point to /var/git with something like

    example.com {
      root * /var/git
      file_server
    }
Your git repository will be instantly accessible via https://example.com/repo.git.