所以我（大部分）不久前就停止使用 GitHub 了。对我来说不幸的是，我的 CMS Grav需要将插件托管在 GitHub 上。由于我的KaTeX 插件是在 Sourcehut 上开发的，这使得发布插件有点困难。不过，我想出了一个巧妙的解决方案——将 Sourcehut 存储库镜像到 GitHub。
这真的比听起来容易！
镜像实际存储库内容
GitHub 中没有内置功能来镜像存储库（与Forgejo不同），但 Sourcehut 构建操作应该可以做到这一点！
首先，我必须创建一个秘密以允许 Sourcehut 推送到 GitHub。我避免使用 SSH 密钥，因为 SSH 密钥可以访问 GitHub 上的所有存储库，而不是 Sourcehut 需要访问的存储库。
镜像过程相当简单！我首先在 GitHub 上创建了一个与 Sourcehut 上的存储库同名的空存储库。创建一个空的存储库非常重要！确保“添加自述文件”、“添加 .gitignore”和“选择许可证”均未标记！
为了让 Sourcehut 推送对此存储库的访问权限，我在 GitHub 的秘密页面上添加了一个细粒度的访问密钥，将到期日期设置为未来一年，仅允许其访问我的插件存储库，并仅授予其“读取访问权限”元数据”和“代码的读写访问权限”。
然后，我将访问令牌添加到Sourcehut 的秘密系统中，格式为~/.git-credentials中的文件，权限为600 ：
https://GITHUB_USERNAME:[email protected]
记下生成的 UUID！
然后，在存储库中，我创建了 Sourcehut 构建文件.build.yml ：
image: alpine/edge secrets: - 4df836f8-5313-40b1-bc4e-b7b20cfd147e # Set your UUID here! environment: REPO: grav-plugin-staticmath GH_USER: 9p4 tasks: - push-to-github: | cd ~/"${REPO}" git config --global credential.helper store git push --mirror "https://github.com/${GH_USER}/${REPO}"
此文件假定 Sourcehut 和 GitHub 上的存储库名称相同。如果名称不同，请将REPO变量保留为 GitHub 存储库名称，并将cd行更改为cd ~/sourcehut-repository-name 。
当您推送包含新更改的存储库时，Sourcehut 应该通知您构建已开始，如下所示：
$ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 20 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 776 bytes | 776.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 remote: Build started: remote: https://builds.sr.ht/~fd/job/1143073 [.build.yml] To git.sr.ht:~fd/grav-plugin-staticmath 2d70c2f..622bbf0 main -> main
转到 URL 以确保推送成功，并查看 GitHub 存储库以检查镜像过程是否有效。
如果是这样，那就太好了！然而，还有一个问题。
阻止 GitHub 上的交互
当然，这只是谜题的一半。还需要防止问题和拉取请求在 GitHub 存储库上打开，而是将交互引导到规范的 Sourcehut 工具。
在 GitHub 存储库的设置中，禁用尽可能多的功能：
不幸的是，您无法禁用 GitHub 上的拉取请求。为了防止创建拉取请求，需要采用不同的方法：拉取请求模板，向用户大喊不要创建拉取请求！
在.github/pull_request_template.md中，我添加了以下内容：
# Your Pull Request Will Not Be Merged This is a mirror of the [ Sourcehut ]( https://git.sr.ht/~fd/grav-plugin-staticmath ) repository. I will close this PR. If you want to contribute, please do so on Sourcehut. [ Here is how ]( https://git-send-email.io ). Yes, it requires sending an email. It's easier than it sounds. [ Direct all attention to the Mailing List ]( https://lists.sr.ht/~fd/grav-plugin-staticmath )
这充其量只是不完美的解决方案。最坏的情况是，人们会忽略该消息并创建拉取请求。在这种情况下，自动关闭所有拉取请求的 GitHub 操作可能是合适的（同时取消对存储库的监视，这样您就不会收到针对每个不阅读说明的个人的垃圾邮件）。
更糟糕的是，现在人们更难（如果不是不可能的话）找到邮件列表和问题跟踪器。我决定在 README 顶部放置一组链接，链接到 Sourcehut 上的相关位置：
- [ Grav StaticMath Plugin ]( https://git.sr.ht/~fd/grav-plugin-staticmath ) - [ StaticMath Server ]( https://git.sr.ht/~fd/staticmath-server ) - [ Issues ]( https://todo.sr.ht/~fd/grav-plugin-staticmath ) - [ Mailing List ]( https://lists.sr.ht/~fd/grav-plugin-staticmath )
这具有提供从 Sourcehut Git 存储库到 Sourcehut 问题跟踪器的链接的奇妙副作用（否则该链接不存在，因为主项目页面是唯一并排包含资源的地方）。
所以呢？
然而到目前为止，GitHub 镜像效果非常好！推送标签会自动进行，人们甚至会制造问题！这确实留下了这样一个问题：由于不在 GitHub 上并且不使用他们的贡献工具（即GitHub 问题、GitHub PR等），我错过了多少贡献者。我的项目足够小且足够稳定，我不必担心关于缺乏贡献者的问题。发现是通过 Grav 的插件页面而不是 GitHub 完成的，因此将规范存储库放在其他地方并没有太大的损害。
不过，我确实有另一个专门保存在 GitHub 上的存储库： jellyfin-plugin-sso 。坦率地说，人们对 Sourcehut 的工作流程感到厌烦，我不怪他们。考虑到与发送电子邮件到~fd/[email protected] （如果我见过的话，这是一个粗略的电子邮件地址）相比，在这个存储库上寻求帮助要容易得多，人们可以获得更多信息帮助，让我的项目变得更好。
源码小屋太棒了！我很失望它没有获得更多关注，但很明显为什么 Sourcehut 在开发者中仍然是一个利基市场。如果您希望围绕您的项目保留一个社区，那么不加区别地将所有内容转移到 Sourcehut 并不是解决方案。我听说过这样的论点：Sourcehut 的模型很好，因为它将“糟糕的程序员”拒之门外。这种精英主义最终会损害开源社区。
如果我能够保留 Sourcehut 的工作流程（我确实对此有一些抱怨，但那是另一次的帖子了），我对 Sourcehut 保持一个利基市场感到非常高兴，但该工作流程对于大多数开发人员来说并不是很好，即使是经验丰富的开发人员，想要为项目提供帮助的人。
考虑一下哪些人会在问题跟踪器上创建问题，哪些人想要进行路过贡献，并问问自己他们是否愿意使用 Sourcehut。
此外，我确信您无论如何都可以针对Codeberg调整这些说明。
一些灵感来自迈克尔·凯利的博客。
更正？评论？只是想打个招呼吗？保持联系！
我很快就会回来写尼克斯的犯罪和奇怪的项目，但是哇，大学很难。如果我决定开始发表我必须为我的课程写的论文，每周一篇文章可能会重新出现，但不要指望它。