Yes, that’s true for the git repo itself, but a git forge can provide a multitude of related services, including issues and pull request management, CI/CD pipelines, wikis, static content hosting, package registries, etc. which are not as easily migrated.
Something’s are more inherent to git forges imho
Like forking, merge requests, secret branches, and team permissions.
I would prefer those be behind an API and fed into a more flexible UI honestly with the other panels being user defined views to other tools. Like a UI for tekton. A UI for Caddy or hugo or something. A UI for your issues tracker. Etc.
Even better if it federates those backends…
Maybe let the site admin have a list of approved views and configs so people aren’t putting compromised views on the site.
I honestly think wiki, static hosting, package registries etc. don’t belong on a git repo. Github has continuously extended their feature-set, but its caused vendor lock-in which I think is the point. How hard is it to spin up a web service to host static content? There are loads of good open source wiki projects, etc.
Depends on the point of the wiki I feel, if it’s project documentation it should be in git alongside the code, if it’s a generic “document store” then yeah there’s better storage backends than git.
Why do it yourself in a complicated way and poke holes in my firewall and security if I can use the existing infrastructure that is already a publiclly accessible web page to host just another one? ¯\_(ツ)_/¯
Yes, that’s true for the git repo itself, but a git forge can provide a multitude of related services, including issues and pull request management, CI/CD pipelines, wikis, static content hosting, package registries, etc. which are not as easily migrated.
Something’s are more inherent to git forges imho Like forking, merge requests, secret branches, and team permissions.
I would prefer those be behind an API and fed into a more flexible UI honestly with the other panels being user defined views to other tools. Like a UI for tekton. A UI for Caddy or hugo or something. A UI for your issues tracker. Etc.
Even better if it federates those backends…
Maybe let the site admin have a list of approved views and configs so people aren’t putting compromised views on the site.
I honestly think wiki, static hosting, package registries etc. don’t belong on a git repo. Github has continuously extended their feature-set, but its caused vendor lock-in which I think is the point. How hard is it to spin up a web service to host static content? There are loads of good open source wiki projects, etc.
Depends on the point of the wiki I feel, if it’s project documentation it should be in git alongside the code, if it’s a generic “document store” then yeah there’s better storage backends than git.
Why do it yourself in a complicated way and poke holes in my firewall and security if I can use the existing infrastructure that is already a publiclly accessible web page to host just another one? ¯\_(ツ)_/¯