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

Question

У меня есть небольшая настройка git-репо с единственной реальной целью, чтобы иметь возможность локально разрабатывать на нескольких машинах (работа, дом, ноутбук). Таким образом, у меня есть одна ветвь, и я фиксирую / толкаю, как только выхожу из компьютера, тяну, когда я сижу за следующей. Работал нормально, до сих пор так и есть. Теперь, когда я использую мой тестовый компьютер, я получаю следующее:

remote: Counting objects: 38, done.
remote: Compressiremote: ng objects: 100% (20/20), done.
remote: Total 20 (delta 17), reused 0 (delta 0)
error: unable to create temporary sha1 filename .git/objects/ed: File exists

fatal: failed to write object
fatal: unpack-objects failed

Поиск по сети: единственный реальный ответ, который я смог найти, был следующий: http://marc.info/?l=git&m=122720741928774&w=2, который в основном утверждает, что это ложная ошибка, которая находится на вершине кучи, и, таким образом, ничего не говорит о том, что на самом деле неправильно. 1006 *

Куда мне пойти отсюда, чтобы узнать, что не так?

Редактировать: удалил локальную копию и повторно клонировал

Answer 1

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

Answer 2

Упоминается в " Re: Bug? Git svn fetch:" невозможно создать временное имя файла sha1 /home/andres/git/public/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

Answer 3

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

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

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.

Answer 4

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

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

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

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

Answer 5

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

dieter@dieter-dellD620-arch 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 gitosis@tiktak.kangaroot.net: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 'gitosis@tiktak.kangaroot.net:sugarcrmclient.git'

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

Answer 6

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

Затем я запускаю git gc, все работает.

Из руководства пользователя git-gc (1):

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

Answer 7

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

Я только что провел небольшое расследование, и, похоже, что-то происходит с разрешениями: перед принудительным размещением в репо (то есть в репозитории, размещенном на сервере) все файлы в объектах имеют разрешения -rw-rw-r-- набор, который вы ожидаете. Все они принадлежат одному пользователю и группе. После неудачной отправки я могу выполнить поиск файлов с разрешениями, установленными на -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 обновляет / заменяет файлы (дает им новую временную метку), изменяет разрешения в процессе, а затем жалуется на разрешения. Я полностью озадачен тем, что здесь происходит: (

Answer 8

У меня проблема с разрешением

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

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

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

Answer 9

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

chown -hR MyGitUser MyRepo

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

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

Answer 10

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

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

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