GitHub 仓库突然收到大量 Stars，没找到原因……

• 資深大佬 : heiybb

  https://twitter.com/D0nA1dJ0hNT3UmP/status/1251971144007077888

• 資深大佬 : heiybb

  @heiybb #1 点进 Thread 看，就有你这个 rep 的直链了
  会不会是从这过去的
  时间点也差不多能对上

• 資深大佬 : lostpg

  好评！

• 主 資深大佬 : h404bi

  @heiybb 谢谢谢谢，应该是，破案了。原来是 tweet 上被分享，链接在 traffic 里没有来源真不好排查。

• 資深大佬 : Jirajine

  有个小问题，你这个库里面有不少应用和官方库有重名的，不知道安装的时候 scoop 会装哪个？
  个人觉得官方库里有的和通用的软件应该合并提交到官方仓库，这个库只单独维护一些本地化的软件即可。

• 資深大佬 : rosu

  仓库 insight — traffic 里有访问来源。
• 主 資深大佬 : h404bi

  @rosu 就是 traffic 里看不到有异常的 referral 才一脸懵逼

• 主 資深大佬 : h404bi

  @Jirajine 理论上应该是 main bucket 的权重是最高的，实际上 scoop 还没有做 bucket 权重的 feature，好像是按 bucket 克隆到本地后的名字按字母顺序先后查找 manifest 。我这个库里跟主库有重的原因有两个，一个是有些 package 是先于主库创建的，后面有其他用户加到主库里了。另一个原因是有些 package 我觉得主库的 manifest 写得不太好影响使用，就自定义了一份。有想过给重复的 manifest 改名，但是改名 /删除都会影响 end users，所以一般只增不减。

• 資深大佬 : Jirajine

  @h404bi scoop 这个不完善就有点坑，不但你维护时需要重复不必要的工作，还可能因更新不及时、版本差异造成其他难以排查的 bug 。
  我觉得还是得尽早解决，比如给重名的应用发布更新标记为 deprecated 提示用户并 suggest/depend 对应主仓库的包或改名后的自己的修改包让他们迁移，不然时间长了历史包袱越来越重就很麻烦了。

• 主 資深大佬 : h404bi

  @Jirajine 我用了 5 年 scoop 了。其实除了 bucket 的一些问题外，scoop 还有不少其他方面的问题。不过还好不是非常严重，核心功能还是很好用的，而且一些问题 backlog 也被解决掉了。scoop 的开发活跃度不高，问题只能慢慢处理啦。

• 資深大佬 : fangxing204

  我在 Twitter 上看有人推荐你这个的

• 資深大佬 : BenX

  好像昨天有个群里讨论了这个，顺手点了一个 star