не удалось заблокировать ссылки / главы / мастер удаленного репо

Question

Мои проблемы относятся к ситуации, описанной в этом посте .В двух словах, есть удаленный репозиторий с открытыми и открытыми репозиториями.Согласно плану, мало кто (включая меня) должен иметь возможность перенести свои изменения в репо.Файл hooks/post-receive позволяет автоматически вносить эти изменения в репозиторий non-bare на сервере.Это содержимое файла:

!/bin/sh
cd /data/11_prywatne/14_Pawel/repo_pawel_non_bare/deploy || exit
unset GIT_DIR
git pull origin master

`chmod g+rwx -R /data/11_prywatne/14_Pawel/repo_pawel_non_bare/deploy/ &> /dev/null`

Все шло хорошо, пока я был единственным, кто толкал и тянул к непрошеному репо.Однако однажды у другого человека git push origin master возникли некоторые проблемы.Например, при попытке git pull origin master в удаленном репозитории non-bare (я знаю, что в этом нет необходимости, поскольку hooks/post-receive) я получил эту ошибку:

fatal: Couldn't find remote ref master
fatal: The remote end hung up unexpectedly

Я попытался проверить с помощью git log (на удаленном не-голом) что история коммитов и получила эту ошибку:

error: Could not read <hash of the commit made by the other person>
fatal: Failed to traverse parents of commit 68e6227f4c4f84843ed7dd4fc03a159

git status (на удаленном не-голом) возвращает следующий вывод:

# On branch master
error: Could not read <hash of the commit made by the other person>
error: Could not read <hash of the commit made by the other person>
fatal: Failed to traverse parents of commit 68e6227f4c4f84843ed7dd4fc03a15967051a97f

git push origin master (на удаленном не голом) возвращает:

error: Could not read <hash of the commit made by the other person>
fatal: Failed to traverse parents of commit 68e6227f4c4f84843ed7dd4fc03a15967051a97f
error: pack-objects died with strange error

(все еще на удаленном не голом), тогда я решил git reset --hard, и все казалось нормальным, но git push origin master получаетя:

error: unable to resolve reference refs/heads/master: Permission denied
remote: error: failed to lock refs/heads/master
To /data/11_prywatne/14_Pawel/gole.git/
 ! [remote rejected] master -> master (failed to lock)
error: failed to push some refs to '/data/11_prywatne/14_Pawel/gole.git/'
[user@server deploy]$ git pull origin master
fatal: git upload-pack: cannot find object <hash of the commit made by the other person>:
fatal: The remote end hung up unexpectedly

Я переключился на локальный репо и попытался нажать.Я получил те же ошибки, которые указали, что проблема вызвана Permission denied.Я попросил другого человека установить групповые разрешения для файла, который находится в голом хранилище refs/heads/master.Проблема, казалось бы, была решена, но другая попытка произошла при попытке git push origin master:

error: Ref refs/heads/master is at <hash of the commit made by the other person> but expected 0000000000000000000000000000000000000000
remote: error: failed to lock refs/heads/master
To server_ip:/data/11_prywatne/14_Pawel/gole.git/
 ! [remote rejected] master -> master (failed to lock)
error: failed to push some refs to 'user@server_ip:/data/11_prywatne/14_Pawel/gole.git/'

При попытке git pull origin master я получаю:

fatal: git upload-pack: cannot find object <hash of the commit made by the other person>:
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Просто для пояснения.Это содержимое .git/config на моем локальном компьютере:

[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        symlinks = false
        ignorecase = true
[remote "origin"]
        url = user@server_ip:/data/11_prywatne/14_Pawel/gole.git/
        fetch = +refs/heads/*:refs/remotes/origin/*

Файл .git/config на компьютере другого человека отличается только в том, что касается URL-адреса, на который он указывает (user2@server:/data/11_prywatne/14_Pawel/gole.git/).

Тот же файл, но в репозитории non-bare на сервере:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = /data/11_prywatne/14_Pawel/gole.git/
[branch "master"]
        remote = origin
        merge = refs/heads/master

Возможно, я пропустил некоторые шаги при создании репо non-bare.Должен ли я рассмотреть некоторые внутренние параметры git, которые позволяют создавать общие репозитории, не являющиеся открытыми?Означает ли мое использование chmod, что я допустил ошибку?Как я могу решить проблему с?

Answer 1

Это проблема с разрешениями файловой системы, возможно, вызванная тем, что люди, которые переходят в пустой репозиторий, делают это, используя разные системные учетные записи.Вы должны помнить, что скрипты хуков запускаются под одной учетной записью.Если какое-либо из разрешений как в чистом, так и в непокрытом хранилище слишком ограничено, для пользователя A будет невозможно пройти это полностью после того, как пользователь B также нажал - некоторые файлы и внутренние подкаталоги Gitбудет принадлежать A, а некоторые - B.

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

Однако этого по-прежнему недостаточно, поскольку --shared влияет только на собственные метаданные Git, а не на рабочее дерево.Ваша попытка все еще может потерпеть неудачу из-за неспособности фактически проверить файлы.Каждый раз, когда операция извлечения создает новые каталоги, разрешения для них могут быть слишком строгими.

Исправление этого выходит за рамки Git - вы можете захотеть посмотреть:

• Чтобы все пользователи изменили свой umask по умолчанию в своих учетных записях на этом компьютере;
• Установка общей первичной группы пользователей для всех этих пользователей (не всегда возможно) ИЛИ
• Использование POSIX ACL (которыепо общему признанию, это может быть довольно запутанным).

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