# Non-github (non gitlab) git repositories... anyone using them ? Good or bad idea for Julia packages?

**URL:** <https://discourse.julialang.org/t/non-github-non-gitlab-git-repositories-anyone-using-them-good-or-bad-idea-for-julia-packages/128999>\
**Category:** Offtopic\
**Created:** [May 14, 2025, 3:17pm UTC](https://discourse.julialang.org/t/non-github-non-gitlab-git-repositories-anyone-using-them-good-or-bad-idea-for-julia-packages/128999 "2025-05-14T15:17:40Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [May 14, 2025, 3:17pm UTC](https://discourse.julialang.org/t/non-github-non-gitlab-git-repositories-anyone-using-them-good-or-bad-idea-for-julia-packages/128999/1 "2025-05-14T15:17:40Z")

</div>

I have just discover today the likes of [codeborg](https://codeberg.org/) and [Forgejo](https://forgejo.org/), i.e. “community” driven (or even self-hosted) git repository hosting, and wondered if anyone use them in place of more mainstream github or even gitlab alternatives, and if you think is a good idea to host Julia packages there.. perhaps “proxied” by a zenodo entry to guarantee “permanence” ???

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [May 14, 2025, 3:28pm UTC](https://discourse.julialang.org/t/non-github-non-gitlab-git-repositories-anyone-using-them-good-or-bad-idea-for-julia-packages/128999/2 "2025-05-14T15:28:52Z")

</div>

For what it’s worth the General registry currently has five packages by one user hosted on codeberg. The major drawback is that the Registrator functionality is not available, so all update PRs must be made manually (which isn’t that hard with LocalRegistry) and are thus not supported by automerge and must be reviewed and merged manually.

The more convenient workaround for General packages is to mirror them to GitHub or GitLab.

---

<div class="post-metadata">

**Author:** ![tecosaur](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tecosaur/32/23206_2.png) [@tecosaur](https://discourse.julialang.org/u/tecosaur)\
**Post date:** [May 14, 2025, 6:24pm UTC](https://discourse.julialang.org/t/non-github-non-gitlab-git-repositories-anyone-using-them-good-or-bad-idea-for-julia-packages/128999/3 "2025-05-14T18:24:45Z")

</div>

> [@GunnarFarneback](#):
>
> The more convenient workaround for General packages is to mirror them to GitHub or GitLab.

This is what I’m doing with most of my packages these days.

---

<div class="post-metadata">

**Author:** ![LeePhillips](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/leephillips/32/205514_2.png) [@LeePhillips](https://discourse.julialang.org/u/LeePhillips)\
**Post date:** [May 14, 2025, 6:34pm UTC](https://discourse.julialang.org/t/non-github-non-gitlab-git-repositories-anyone-using-them-good-or-bad-idea-for-julia-packages/128999/4 "2025-05-14T18:34:20Z")

</div>

I put all the code examples in my book in a registry that I created for that purpose.

The disadvantage of not using GitHub is that you deny its “AI” tools the ability to steal your code.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [May 14, 2025, 9:15pm UTC](https://discourse.julialang.org/t/non-github-non-gitlab-git-repositories-anyone-using-them-good-or-bad-idea-for-julia-packages/128999/5 "2025-05-14T21:15:51Z")

</div>

> [@GunnarFarneback](#):
>
> The major drawback is that the Registrator functionality is not available, so all update PRs must be made manually

Relevant issues:

- [cannot register Codeberg-hosted package · Issue #160 · JuliaComputing/JuliaHub-Feedback · GitHub](https://github.com/JuliaComputing/JuliaHub-Feedback/issues/160)

- [[Feature request] Codeberg support · Issue #430 · JuliaRegistries/Registrator.jl · GitHub](https://github.com/JuliaRegistries/Registrator.jl/issues/430)

- [[Feature request] Codeberg support · Issue #49 · JuliaWeb/GitForge.jl · GitHub](https://github.com/JuliaWeb/GitForge.jl/issues/49)

---

<div class="post-metadata">

**Author:** ![ImreSamu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/imresamu/32/20677_2.png) [@ImreSamu](https://discourse.julialang.org/u/ImreSamu)\
**Post date:** [May 15, 2025, 1:12am UTC](https://discourse.julialang.org/t/non-github-non-gitlab-git-repositories-anyone-using-them-good-or-bad-idea-for-julia-packages/128999/6 "2025-05-15T01:12:18Z")

</div>

> [@LeePhillips](#):
>
> The disadvantage of not using GitHub is that you deny its “AI” tools the ability to steal your code.

If a project is open source, you can always fork it ; ~ create a copy on GitHub , so hosting it elsewhere is only a minor inconvenience, not a real barrier.  
However, this can sometimes cause problems: if someone forks the project on GitHub and everyone opens issues there but nobody responds, many people may assume the project is no longer active ( or dead ) . 😭

What I’ve noticed is that PostGIS ( [Source Code | PostGIS](https://postgis.net/development/source_code/#source-code-repository) ) has two mirrors. The original git server is so underpowered that just twenty simultaneous `git clone` operations can overwhelm it - which is easy to trigger with a CI. Because of this, the official [docker-postgis](https://github.com/postgis/docker-postgis) image uses the GitHub mirror at [GitHub - postgis/postgis: PostGIS spatial database extension to PostgreSQL [mirror]](https://github.com/postgis/postgis/)

Another benefit of GitHub is that projects are more visible - when someone searches for a solution, GitHub is usually the first place they look.

On the other hand - it’s still useful to have access outside of GitHub so everyone can use their preferred platform and you have an extra backup.