0

I was trying to push a single pdf file and I got this error:

error: unable to write sha1 filename ./objects/54/1cc9d1b18f218c85f9d7f5fe7a129ab595f: No such file or directory
To git@gitlab.com:myrepo
 ! [remote rejected] master -> master (unable to migrate objects to permanent storage)
error: failed to push some refs to 'git@gitlab.com:myrepo

Any Idea what has happened!? What is this sha1 file!?

yukashima huksay
  • 5,834
  • 7
  • 45
  • 78
  • Possible duplicate of [What does git mean by, "unable to migrate objects to permanent storage"?](https://stackoverflow.com/questions/42214667/what-does-git-mean-by-unable-to-migrate-objects-to-permanent-storage) – phd Jan 07 '18 at 02:19

1 Answers1

0

That's odd: the initial error message should have been prefixed by the word remote:, i.e.:

remote: error: unable to write sha1 filename ./objects/54/1cc9d1b18f218c85f9d7f5fe7a129ab595f: No such file or directory
To git@gitlab.com:myrepo
 ! [remote rejected] master -> master (unable to migrate objects to permanent storage)
error: failed to push some refs to 'git@gitlab.com:myrepo

That would make sense, but this error, without the remote: prefix, does not.

Any error prefixed by the word remote: is coming from another Git. When you run git push, your Git calls up another Git and sends information (including Git objects) to that other Git. That other Git does some verification to determine whether or not your git push is allowed. Once it's done all the checking, and has decided that the update is allowed, that Git finishes by incorporating the objects into its repository and finalizing everything.

If the error had been prefixed by remote:, this would then make sense: the remote—the other Git—tried to finalize everything, but something went wrong during this process. They then let your Git know that the problem occurred, so your Git copied the error message through, prefixing it with the word remote:, then your Git printed the last three lines on its own, letting you know that something went wrong.

In short, this would mean that the problem is on another computer, not on your computer. You must show it to whoever manages that other computer (on gitlab.com), and have them see what's wrong with their system.

But without the remote:, none of this analysis quite holds up.

torek
  • 448,244
  • 59
  • 642
  • 775
  • what does sha1 mean!? could it be bc of low mem or disk? – yukashima huksay Jan 07 '18 at 14:18
  • The `sha1` is the internal hash Git uses. With a `remote:`, "low disk space on the other computer" would make sense, as would permissions errors: Git uses the hash ID of the object to form the name of the file that will store the data associated with that key. Modern Gits, when taking incoming objects, store them in a "quarantine" area until they decide to accept them, then copy them to permanent storage, and with `remote:` in front of this error message, that would indicate that the remote Git has failed to copy the object to permanent storage. – torek Jan 07 '18 at 17:39
  • Once again, though, *none of this is correct* if the error message *doesn't* start with `remote:`. Moreover, if the error message *does* start with `remote:`, *none of this problem is at your end.* – torek Jan 07 '18 at 17:40
  • How much upload is likely to make trouble for the remote gitlab machine?! I uploaded around 30GB. I didn't get your explanation about sha1. I thought you said it was the hash of the object I had tried to send but actually I got this error twice for different files in different times so I don't expect my objects to have the same hash. I'm not sure about the remote thing the error happened a while ago and now it's gone. I'll make sure if it happened again. – yukashima huksay Jan 07 '18 at 17:51
  • 30 GB might be too big for them. It's hard to say: if the problem is in Chicago, it won't matter how carefully you inspect the building in Kyoto. As for the hash ID: the hash ID of any object is determined entirely by the contents of that object. The same file will always have the same hash ID, but two different files you will get two different hash IDs. – torek Jan 07 '18 at 17:53