在 Github 上所做的更改并不像预期的那样
近日有报道称 GitHub改变了生成文件的方式 在启动页面上自动生成“.tar.gz”和“.tgz”。
这个变化 导致校验和发生变化并导致构建系统发生大规模崩溃 自动化，它根据先前存储的校验和验证从 GitHub 下载的文件的完整性，例如放在包元数据或构建脚本中的校验和。
从 Git 的 2.38 版开始， 默认包含 gzip的集成实现， 这使得在所有操作系统中统一支持这种压缩方法并提高文件创建性能成为可能。 GitHub 在升级其基础设施上的 git 版本后获取了更改。
Git 文件的默认压缩最近发生了变化。 因此，从 GitHub 下载的文件可能有不同的校验和，即使内容没有完全改变。
GitHub 不保证自动生成文件的校验和的稳定性。 这些在“版本”选项卡中标有“源代码（zip）”和“源代码（tar.gz）”字样。 如果需要依赖一致的校验和，可以将文件直接上传到 GitHub Releases。
这些保证不会改变。
问题是 比文件 生成的片剂 通过 gzip 实现 zlib 构建是不同的二进制文件 gzip 实用程序生成的文件， 这导致不同的校验和 对于执行“git archive”命令时由不同版本的 git 创建的档案。
因此，在 GitHub 上更新 git 之后，发布页面上开始出现略有不同的文件 使用上述校验和验证失败。
这个问题在各种构建系统、持续集成系统和用于从源构建包的工具包中表现出来。 例如，FreeBSD 大约有 5800 个端口被破坏，其源是从 GitHub 下载的。
作为回应 对于第一次关于失败的抱怨， GitHub 代表最初指出，校验和从未得到保证 文件常量。
在表明使构建系统受更改影响需要大量工作来更新各种生态系统中的元数据之后，GitHub 改变了主意，恢复了更改并恢复到旧的文件生成方法。。
不出所料 人们开始抱怨. GitHub 员工（和顶级 Git 贡献者）brian m 的初步回应。 卡尔森还没有完全理解：
我是说政策从来都不是正确的，我们从来没有保证文件的校验和稳定，就像 Git 从来没有保证过一样。 对于此处无法正常工作的事情，我深表歉意，过去没有对此进行更清晰的沟通，但我们的政策已经 4 年多没有改变。
Git 开发人员 他们还没有做出决定，只是在讨论可能采取的行动。 该 考虑的选项包括求助于使用 gzip 实用程序 默认; 添加“–stable”标志以保持与旧文件的兼容性； 将内置实现链接到单独的文件格式； 对旧提交使用 gzip 实用程序，对特定日期的提交使用内置实现； 只保证未压缩文件的格式稳定性。
决定的复杂性是因为恢复到外部实用程序调用并不能完全解决校验和不变性问题，因为外部 gzip 程序的更改也会导致文件发生更改。
目前，有一个补丁集供审查，它恢复到默认行为（调用外部 gzip 实用程序）并在系统上不存在 gzip 实用程序时使用内置实现。 这些补丁还在文档中添加了一条注释，即不保证“git archive”的输出是稳定的，并且格式将来可能会发生变化。
最后 如果您有兴趣了解更多有关它的信息，您可以在中查看详细信息 以下链接。