Moving the pfSense® Documentation to GitHub
-
https://www.netgate.com/blog/moving-the-pfsense-documentation-to-github.html
-
Any concerns with MS buying github?
-
If they start acting all Microsofty, everything can be moved to Gitlab or some other Git host.
-
@kom said in Moving the pfSense Documentation to GitHub:
Microsofty
heheeh Love the term ;) Yeah I was just curious since announce move same time MS buys them..
Pretty sure MS will find a way to dick up a good thing.. ;)
-
I'm sure they will find a way to Embrace and Extend git, they've already been shady with the GVFS situation. "Because Microsoft" isn't a compelling reason to run away just yet.
We don't have any private info on github that we don't want Microsoft to get their hands on, like some organizations do. It's all open source stuff, and most of it is actually mirrored/pushed from our internally hosted Gitlab instance.
The nature of git makes it easy to move if we have to, but we're not quite to that point yet.
-
With GIT, every copy of the repo is a repo in itself so if Github suddenly starts putting any restrictions on the usage you can take your repos elsewhere.
-
@kpa said in Moving the pfSense Documentation to GitHub:
With GIT, every copy of the repo is a repo in itself so if Github suddenly starts putting any restrictions on the usage you can take your repos elsewhere.
The only parts you could lose in the process are specific to Github, like PRs, issues (if you use them), access controls on repos, and so on. But the contents are always easy to shove wherever you want with git.
-
@jimp said in Moving the pfSense Documentation to GitHub:
The only parts you could lose in the process are specific to Github, like PRs, issues (if you use them), access controls on repos, and so on. But the contents are always easy to shove wherever you want with git.
Right, and as you are using internal systems to push that out to Github and run Redmine as issue tracker, you actually don't use that much Github specific features that would depend on the platform to continue as-is ;) Loosing issue/ticket informations (when using GitHub internal issue tracking) would be worse.