6

如果你去https://packagist.org/packages/geekality/website并将其与运行 `composer show geekality/website.

  1. 顶部packagist的最新版本是v0.7
  2. 命令行输出中给出的最新版本是 v0.6
  3. 在这两种情况下，最新版本都应该是 v0.7.1
  4. 版本 >= 0.7 甚至不会出现在命令行中
  5. dev-master 版本指向 v0.5 ??

这里发生了什么？我该如何解决？如果我将 composer.json 更改为目标版本/标签 0.7.1，对我来说，这显然存在于 packagist 和 GitHub 上，我会收到一条错误消息，指出找不到请求的包。

我努力了

  • 删除供应商文件夹并重新更新
  • 删除作曲家缓存
  • 在另一台计算机上更新作曲家
  • 在 Packagist 上删除并重新创建包
  • 创建并推送新标签（0.7.1与0.7基本相同）

有人知道发生了什么吗？

更新

似乎这是由 Packagist 的一些问题引起的，而我这边（或其他似乎有同样问题的人）实际上并没有错。

我通过在composer.json.

4

2 回答 2

4

这种情况下的解决方案是等待 Packagist 不被破坏。

所以，如果其他人有这个问题并且他们已经检查了他们所有的东西，也许可以查看推特或其他东西，看看其他人是否有问题。

于 2014-10-28T13:13:56.173 回答
2

看起来您填充了标签或将源/主服务器移回了早期版本。

Svish php-web 的标签

版本 v0.5 仍然具有与之关联的origin/masterandmaster标记，这很奇怪。

我认为您只想将 master 重置为最新的提交，但是您可能应该首先弄清楚这是如何发生的，以防发生更奇怪的事情。

我标记版本的方式是：

  1. 签入并将所有内容推送到远程存储库。
  2. git tag 1.2.3在命令行上运行。
  3. 在命令行推送标签git push --tags

我认为您可能是通过跳过第 1 步并在本地仍有未提交的更改而导致此问题的。如果您可以推送这些提交，那可能会解决问题，否则您可能需要将头部重置为适当的版本。

在 Atlassian Sourcetree 中，可以通过右键单击相应的签入来完成，否则您可以使用以下git reset命令从命令行执行此操作：

git reset --soft a4ed43d16ecb20aaa275ee120e073e043190e093

完全不触及索引文件或工作树（但将头部重置为 ，就像所有模式一样）。正如 git status 所说，这会使您所有更改的文件都“提交更改”。

这不应该在本地或远程删除任何东西，而只是改变头部指向的位置。

于 2013-06-06T13:47:35.280 回答