Hi,
On Fri, 07 Feb 2025 at 16:22, Ludovic Courtès <l...@gnu.org> wrote:
> • Scalability (storage): If the Guix repository were to have “tens of
> thousands” of forks (I think these were their words), then the
> storage requirements for Codeberg could be very high and
> problematic, due to lack (or partial lack, I’m not sure) of
> deduplication across forks.
Hum, interesting. I thought that deduplication was (almost) free by
design of Git. Anyway.
Well, maybe not “tens of thousands” but I bet on thousands in the coming
months after the move, if any.
Especially when it becomes so “easy” (familiar) to click on a button for
forking. Without counting on the “wish-to” effect: I would like to
contribute and even if I will never do it, I start to fork in case.
Here the numbers of contributors per year:
--8<---------------cut here---------------start------------->8---
$ git log --pretty='format:%cd,%an' --date=format:'%Y' | sort | uniq | cut
-d',' -f1 | uniq -c
4 2012
14 2013
36 2014
59 2015
114 2016
119 2017
136 2018
187 2019
262 2020
331 2021
350 2022
363 2023
377 2024
133 2025
--8<---------------cut here---------------end--------------->8---
Let as an exercise the prediction for 2025 and later. :-)
And based on “git shortlog”, I count 284 single-time contributor. And
around one hundred over the past year.
Therefore, I bet on thousands. :-)
> They mentioned the AGit workflow as a way to avoid that
> fork/branch/pull-request mechanism and its associated costs:
> https://forgejo.org/docs/latest/user/agit-support/
Please note that a patch had been sent to Git upstream [1] but something
makes it stale. And the tool mentioned by AGit original author, namely
git-repo [2], had been archived recently. However ’repo’ [3] seems
still developed.
Maybe this post is worth reading:
https://git-repo.info/en/2020/03/agit-flow-and-git-repo/
1:
https://public-inbox.org/git/20200304113312.34229-1-zhiyou...@alibaba-inc.com/
2: https://github.com/alibaba/git-repo-go
3: https://gerrit.googlesource.com/git-repo
> • Software Heritage has a hard time archiving code at Codeberg due to
> rate limiting. Apparently the two parties are now discussing it.
Cool! Glad to ear to that.
Cheers,
simon
