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.
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.
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? ¯\_(ツ)_/¯
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.
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.
That’s the genius of git: it’s not tied to any website. Pull your repo from here and push it to there and you’re cooking.
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.
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.
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? ¯\_(ツ)_/¯
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.
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.
Git forges provides a lot of features these days now. From Merge requests, forks, issues tracking, secret branches, to team management stuff.
A lot more stuff gets bolted onto but they are arguably more optional but for some are the point lol
Like ci/cd at the forge level is the best to me for dev centric flows
Are you a git expert ?