Ошибка получения по запросу мерзавца: не мог создать временное sha1 имя файла

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

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

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

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

Вы пробовали переупаковку?

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

И Вы пытались обновить до последней версии Мерзавца?

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

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

Как упомянуто в "Мерзавце Сборка "мусора", кажется, полностью не работает", a git gc --aggressive ни один достаточно или даже достаточно самостоятельно.

Самая эффективная комбинация добавила бы git repack, но также и git prune:

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

My issue was a permission problem

I went up directory then cp -R repo repo_copy

then everything worked again.

then I went to delete repo and permission denied, checked perms and sure enough perms had been changed that the user I was running as didn't have write access...

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

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

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

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

Я видел эту ошибку, когда несколько пользователей фиксируют один и тот же репозиторий, что приводит к проблемам с правами групповой записи как следствие 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.