Git ошибка pull: невозможно создать временное имя файла sha1

Ответ 1

Для чего это стоит, когда у меня была эта проблема, но когда я совершал ошибку, я пробовал git-repack и git-gc, но не работал. Я получил ошибку с разрешением, которая привела меня к chown всей репо рекурсивно для пользователя, которого я ожидал, и я мог бы тогда совершить/нажать/вытащить без проблем.

Ответ 2

Это упоминается в Re: Ошибка? git svn fetch: "не удалось создать временное имя файла sha1/home/andres/git/общественности/crystal.g":

После переупаковка в репозитории проблема исчезла. Действительно странно.

Вы пытались переупаковать?

git-repack используется для объединения всех объектов, которые в настоящее время не находятся в "пакете", в пакет. Он также может быть использован для реорганизации существующих пакетов в единый, более эффективный пакет.
Пакет представляет собой набор объектов, индивидуально сжатых, с применением дельта-сжатия, хранящихся в одном файле, с соответствующим индексным файлом.
Пакеты используются для уменьшения нагрузки на зеркальные системы, резервные двигатели, дисковое хранилище и т.д.

И вы пытались перейти на последнюю версию git?

У вас есть разные команды для запуска, чтобы "очистить" ваш репозиторий, от самых безопасных до более агрессивных:

$ git-prune
$ git-gc --aggressive
$ git-repack
$ git-repack -a
$ git-prune-packed

Как упоминалось в "Git сбор мусора, похоже, не полностью работает, git gc --aggressive не является достаточным или даже достаточно само по себе.

Наиболее эффективной комбинацией будет добавление git repack, но также git prune:

git gc
git repack -Ad      # kills in-pack garbage
git prune           # kills loose garbage

Ответ 3

У нас была та же проблема, в которой пользователь 1 ранее выполнял, после чего каталог объектов /ed был создан и принадлежал пользователю 1. Поскольку права пользователя 1 по умолчанию не позволяли писать пользователю 2, пользователь 2 не мог зафиксировать.

git создает эти каталоги как хэш-ведра какого-то типа по требованию, поэтому вполне возможно, что они могут принадлежать нескольким другим людям с разными разрешениями в соответствии с их umask.

Мы решили это, сначала разбив все каталоги, принадлежащие одной и той же группе, затем chmodding их всех с g + w, чтобы они были записаны в группу и, наконец, установили все umask правильно, чтобы все вновь созданные ведра также были группами записываемые.

Это потому, что мы используем URL-адреса ssh://для проверки из git - я предполагаю, что если бы мы использовали сетевой протокол git, это не произошло бы, потому что демон git имел бы постоянное владение файлами.

Ответ 4

Я видел эту ошибку, когда несколько пользователей фиксируют один и тот же репозиторий, что приводит к проблемам с правами на запись в группе, как следствие ssh и umask

Вы можете создавать новые файлы, сохраняя режим g + w, установив sharedrepository=true в разделе [core] config:

cd /my/shared/repo.git
git repo-config core.sharedRepository true

# (might also need to "chmod -R g+wX ." for each 
# user that owns files in .git/objects)

EDIT:

Этот метод применим только к уже существующим репозиториям. Вы можете сделать это сразу после создания репозитория: git --bare init --shared.

Ответ 5

В моем случае у меня была эта проблема при попытке нажать.

[email protected] sugarcrmclient [master] git push origin
Counting objects: 16, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (12/12), 3.91 KiB, done.
Total 12 (delta 1), reused 11 (delta 1)
error: unable to create temporary sha1 filename ./objects/7a: File exists

fatal: failed to write object
error: unpack failed: unpacker exited with error code
To [email protected]:sugarcrmclient.git
 ! [remote rejected] master -> master (n/a (unpacker error))
 ! [remote rejected] web -> web (n/a (unpacker error))
error: failed to push some refs to '[email protected]:sugarcrmclient.git'

это не проблема разрешения. git gc, git gc --agrressive, git repack или git чернослив локально не помог. Обратите внимание, как ошибка говорит об ошибке "unpacker error", я думаю, что этот ключ, потому что он подразумевает это на другой стороне. Поэтому я пошел в (голый) репозиторий и сделал там git gc. Тогда я мог бы толкнуть.

Ответ 6

У меня возникла эта проблема и чувствую, что я пробовал все вышеперечисленное. Я видел это раньше, и это было связано с разрешениями между разными пользователями, которые нажимают на репо, но в этом случае все подталкивают под одним и тем же пользователем, и только для хорошей меры я (на репо) отдает все нужным пользователю и группа и chmodded u + w и g + w для хорошей меры. Я все еще получаю error: unable to create temporary sha1 filename ./objects/9a.

Я только что провел немного больше исследований и, похоже, что-то происходит с разрешениями: перед нажатием на репо (который является голой репо, размещенной на сервере), все файлы в объектах имеют разрешения -rw-rw-r--, что и следовало ожидать. Все они принадлежат одному пользователю и группе. После неудачного нажатия, я могу grep для файлов с разрешениями, установленными на -r--r--r--, то есть недоступными для записи, и отображать их местоположения с помощью команды bash find . -perm 444 | xargs ls -l. Выполнение этого дает мне следующее:

-r--r--r-- 1 ourusername ourgroupname    730 Nov  4 15:02 ./objects/46/346f550340bc0d3fec24ea42b25999161f8c7a
-r--r--r-- 1 ourusername ourgroupname    177 Nov  4 15:02 ./objects/4c/664ebbfad568de6101a52c01f5117654945d6d
-r--r--r-- 1 ourusername ourgroupname    730 Nov  4 14:36 ./objects/9e/3f572366da9fb319331dfd924ae35cf9fd00ae
-r--r--r-- 1 ourusername ourgroupname    175 Nov  4 14:36 ./objects/aa/f42d7ed706f1d2e4a0aa1c5eb184e17e917204

Это все недавно измененные файлы (во время публикации 4 ноября, 15:08). Таким образом, похоже, что git обновляет/заменяет файлы (дает им новую временную метку), меняя разрешения в процессе, а затем жалуясь на разрешения. Я полностью зациклен на том, что происходит здесь: (

Ответ 7

Я столкнулся с этой проблемой при использовании git push

Затем я запустил git gc, он работает.

Из git -gc (1) Ручная страница:

git -gc - очистка ненужных файлов и оптимизация локального репозитория

Ответ 8

Моя проблема была проблемой разрешения

Я пошел вверх по каталогу, затем cp -R repo repo_copy

тогда все снова работало.

тогда я пошел удалять репо и отказался, проверял perms и, конечно же, было изменено perms, что пользователь, которого я запускал, так как не имел доступа на запись...

Ответ 9

Если кто-то еще получит эту ошибку, я столкнулся с ней, когда работаю над разделом windows-linux. Кажется, что если форматы новой строки преобразуются в окна, в некоторых случаях вы можете зафиксировать их, но git затем преобразуется в формат linux.

Итак, если новые строки были единственным изменением, то теперь у нас было две одинаковые фиксации в строке. Поскольку хеши фиксации генерируются из данных файла фиксации, и каждый из них имеет одинаковые данные, они попадают в один и тот же хеш. По крайней мере, в моем случае это означает, что указывает "Файл существует". git все запуталось.

Я исправил это, выполнив git reset --hard локально и на центральном репо.

Ответ 10

Лично у меня возникла эта проблема, когда я сделал мастер создания координат git. Решение для меня было: На моем сервере я вхожу в систему с корнем в каталоге, который содержит мой репозиторий и рекурсивно:

chown -hR MyGitUser MyRepo

и все работает отлично

У меня есть только один пользователь git, а другие соединяются с ssh путем публикации их открытого ключа. Если вы настроили несколько пользователей git, вы должны сделать то же самое для каждого пользователя.

Ответ 11

Пробовал некоторые из решений, но в итоге понял, что на диске нашего сервера git не осталось свободного места.

Ответ 12

Я видел эту ошибку один раз и отслеживал ее с проблемой разрешений. Я не мог найти, как это было вызвано, но как-то git выполнялось как группа, у которой не было разрешения на запись для какой-либо каталога объектов.

Я не видел в нем очевидной причины и предположил, что это проблема с разрешениями OS X, предположительно из-за неаккуратного make или install.

Ответ 13

У меня была аналогичная ошибка, и это была не проблема с разрешениями (я единственный пользователь репозитория), и ни одна из методов gc/repack не работала. В конечном итоге я просто отодвинул старый удаленный репозиторий и нажал новый. К счастью, это было довольно мало.

Лиам

Ответ 14

Следует отметить, что вам нужно исправить разрешения для репозитория, на который вы нажимаете, а не только на свой рабочий.

Ответ 15

Изменение прав группы пользователей + работало для меня. Я заметил, что некоторые пользовательские коммиты были в разных группах. Изменение всех в ту же группу устранило эту проблему.

Ответ 16

Я получаю такие ошибки при работе над sshfs. Он ремонтирует себя после размонтирования, а затем снова устанавливает ресурс.

Ответ 17

Работа с linux-сервером на локальном Mac - я попробовал несколько предложений выше, не повезло. Перезагрузился, а затем он работал.

Это не очень подходящее решение, но я мог бы помочь кому-то там.

Ответ 18

У меня возникла эта проблема при попытке развернуть на геройку. Оказывается, у меня был драгоценный камень, который написал файл в каталог tmp/, и герою это не понравилось. Взял файл и вуаля, проблема решена. Смотрите это: https://devcenter.heroku.com/articles/read-only-filesystem

Ответ 19

У меня была эта проблема в последнее время, и я пробовал все в этой ветке без везения. На моем VPS было много свободного места на диске, но оказалось, что из-за того, что я не очистил папку развертывания, я превысил лимит inodes (вероятно, из-за JS-библиотек, которые я включил с 100-м файлами, прежде чем хрустить их).

Я удалил загрузку старых развертываний, и все сработало нормально.

Я понимаю, что это немного крайний случай, но это нужно иметь в виду, если все остальное не работает.