一夜之间,5.4万 Star,全部清零。。
共 1818字,需浏览 4分钟
·
2022-04-26 01:14
HTTPie 设计用于测试、调试以及通常与 API 和 HTTP 服务器交互。http
& https
命令允许创建和发送任意 HTTP 请求。它们使用简单自然的语法,并提供格式化和彩色输出。
发生了什么?
Jakub 首先是承认了此次事件是由自己的错误操作导致的:
由于一连串不幸的事件,我不小心把项目的仓库设为了私有,这个操作让 GitHub 连带删除了我们花了 10 年时间建立的社区。
为什么要设为私有
把仓库设为私有就会永久删除所有 Watch 和 Star,这是 GitHub 的一个特性。我也知道这一点,我显然是无意将 HTTPie 设为私有。
之所以会导致这样的结果,最直接的原因是 Jakub 以为自己在一个不同的仓库里面(该仓库没有内容也没有 Star),这是他在一周前创建的,但之前一直没有向里面填充内容。
Jakub 在当时并没有意识到仓库在命名上存在不一致,HTTPie 项目的仓库为httpie/httpie
,而Jakub 想要设置的仓库为 httpie/.github
。
这就是为什么我在没有意识到我的错误时,将
httpie/httpie
设为私有,而不是httpie/.github
当 Jakub 做完操作回到组织页面后,他发现仍然可以看到空的仓库,反而HTTPie 项目仓库消失不见时,他才真正意识到发生了什么。
于是 Jakub 立刻回到设置页面中想要重新将 HTTPie 设为公开。
但 GitHub 在接下来的半个小时内都不允许他这样做,原因是 GitHub 正在 “帮助” 他删除仓库的 Star 和 Watch,无法中途停止这个过程。
GitHub 拒绝恢复
为了尽可能避免损失,事后 Jakub 第一时间与 GitHub 取得联系,希望 GitHub 能够帮助他们恢复原本的数据。
毕竟 GitHub 团队自己就曾经不小心把 GitHub Desktop 应用的仓库设置为私有,并在几个小时内就为自己恢复了一切。
开发人员今天早上错误地将 GitHub Desktop 仓库设为私有,重新修改回来并不会恢复它的 Star 和其他一些东西,因此我们正在从数据库备份中进行恢复。
显然 GitHub 对此是有相关备份的,并且能够通过备份挽回因不小心将仓库设为私有而造成的损失。
但是在 HTTPie 项目的事件中,GitHub 却拒绝这样做,理由是会引发不良的副作用和浪费资源成本。Jakub 甚至向 GitHub 提出经济补偿,也同样遭到了拒绝。
虽然这件事是由于 Jakub 自己错误操作导致的,但他在博客中也提出了一些 GitHub 可以改善的地方,也希望其他项目作者能够避免再犯同样的错误。
首先,他希望 GitHub 能够以更加清晰、明确的方式向用户告知操作的危害性,而不是一句放在任何地方都适用的 “警告:这是一个潜在的破坏性操作”;其次是改善数据库的设计,尽可能使用 “软删除”,并在一定时间范围内延迟 “硬删除”。
通过这次事情呢,也提醒我们以后在操作自己的GitHub开源项目时,还是谨慎一些为好哇~~
推荐阅读:
5T技术资源大放送!包括但不限于:C/C++,Linux,Python,Java,PHP,人工智能,单片机,树莓派,等等。在公众号内回复「1024」,即可免费获取