Composer / Packagist does not give me my last package

Question

If you go to https://packagist.org/packages/geekality/website and compare it with what you get when you run `gerkality / website. composer.

• The latest version of packagist at the top is v0.7
• The latest version specified in the command line output is v0.6
• The latest version should have been v0.7.1 in both cases
• Version> = 0.7 does not even appear on the command line
• Version dev-master points to v0.5 ??

What's going on here? How to fix it? If I change my composer.json to the target version / tag 0.7.1, which obviously exists for me both for packagist and GitHub, I get an error stating that the requested package was not found.

I tried

• Delete vendor folder and re-update
• Delete composer's cache
• Update the composer on another computer.
• Delete and recreate the package on Packagist
• Create and click on a new tag (0.7.1 is basically the same as 0.7)

Does anyone know what is going on?

---

Update

This seems to be caused by some problems with Packagist and that there really is nothing on my side (or others that seem to have the same problem).

I “solved” it temporarily by specifying the source of the problematic repositories manually in composer.json .

Answer 1

The solution in this case was to wait until the Packagist was broken.

So, if someone else has this problem and they checked all their stuff, maybe check twitter or something else to find out if anyone has problems.

Answer 2

It looks like you filled either your tags, or transferred the original / master back to an earlier version.

This is version v0.5, which still has origin/master and master tags that are very odd.

I think you just want to reset master to the last commit, however you should probably figure out how this happened in the first place, if there is something even weirder there.

The way I use tags:

• Go in and push everything to the remote repository.
• Run git tag 1.2.3 on the command line.
• Click tags on the command line git push --tags

I think you might have caused this problem by skipping step 1 and still not having localized changes. If you can push these commits, this may fix the problem, otherwise you may need to reset your head to the corresponding version.

In Atlassian Sourcetree, which can be done by right-clicking on the corresponding check, otherwise you can do this from the command line with the git reset command:

 git reset --soft a4ed43d16ecb20aaa275ee120e073e043190e093 

It does not apply to the index file or the working tree in general (but it resets the head, like all modes). This leaves all of your modified “Changes Must Be Committed” files, as git status would say.

This should not delete anything either locally or remotely, but simply change what the head points to.