Теоретически это уже было исправлено в GitLab. Почему это появляется для вас, я понятия не имею.
Проблема здесь в том, что https://github.com/robbyrussell/oh-my-zsh сам по себе (несколько) сломан. Это не имеет ничего общего с тем, что вы сделали. Между тем, ваша gitlab.com служба настроена на сверхсрочный режим. Это также , вероятно, не имеет ничего общего с тем, что вы делали, но вам нужно будет изменить это, или же отказаться от идеи отправки этого хранилища. до gitlab.com. (Или, возможно, лучше всего сделать так, чтобы они заметили, что их исправление не устранено).
Если вы клонируете URL-адрес выше и запустите git fsck на своем собственном клоне, вы увидите следующее:
$ git fsck
Checking object directories: 100% (256/256), done.
warning in tree 2b7227859263b6aabcc28355b0b994995b7148b6: zeroPaddedFilemode: contains zero-padded file modes
warning in tree a18c4d13c2a5fa2d4ecd5346c50e119b999b807d: zeroPaddedFilemode: contains zero-padded file modes
warning in tree 84df066176c8da3fd59b13731a86d90f4f1e5c9d: zeroPaddedFilemode: contains zero-padded file modes
Checking objects: 100% (21666/21666), done.
Git, конечно, правильно: 1
$ git cat-file -p 2b7227859263b6aabcc28355b0b994995b7148b6
100644 blob f84db6dc27af34f9f8e393f39a8aedf04ef86c0d .gitignore
100644 blob 950f8861bc7ecbc25cd3544bf33e71cfb04a1ae7 README.textile
040000 tree 30b4ef0a0656cc9e2cfd4140a794bc018ab9e7d0 custom
040000 tree 4a22e953b9b4c774b13f78e157cb2f2b994e7b82 functions
040000 tree 56dccf6298605f85fc44025a0135e2dd796c1be9 lib
040000 tree 44f5974bb55c300d23cd39e96b1f7df57c4f9457 log
100644 blob eadf02d00fb0b625f58bd4ef2ea8dd56bcc85aef oh-my-zsh.sh
040000 tree 5ffecc5c15dc9c3458de787e93135da481094717 templates
040000 tree 8a2c7f00e3c74ed417ce7458942b90ba56f4aeed themes
040000 tree d6621bc3b6b3f5d6f70b119bade00a7d39494695 tools
Все те записи, которые читают 040000, должны читать 40000. Внутренний формат объекта Git требует, чтобы mode записи , а не были дополнены нулями слева.
Что означает , что означает, что независимо от того, создал этот репозиторий, создан тот, который нарушает правила. Однако, как вы можете видеть из моего собственного вывода git fsck, это конкретное нарушение правил вызывает предупреждение , а не прямую ошибку, из git fsck.
Всякий раз, когда вы настраиваете сервер Git, например, создавая gitlab.com и продавая его пользователям, вы можете выбрать, как управлять переменными git config в новых создаваемых вами репозиториях. Это зависит от вас, или в данном случае от них - людей, контролирующих gitlab.com - сделать это. Кто бы они ни были, они установили регуляторы жестче, чем значения по умолчанию. (См. Также это уведомление 2014 года .)
Документация git config говорит об этом receive.fsckObjects:
Если установлено значение true, git-receive-pack проверит все полученные объекты. Смотрите transfer.fsckObjects, что проверено. По умолчанию false. Если не установлено, вместо этого используется значение transfer.fsckObjects.
Между тем секция transfer.fsckObjects читает, частично:
Когда fetch.fsckObjects или receive.fsckObjects не установлены, вместо этого используется значение этой переменной. По умолчанию установлено значение false.
Если установлено, выборка или получение будут прерваны в случае уродливого объекта или ссылки на несуществующий объект. Кроме того, проверяются различные другие проблемы, включая устаревшие проблемы (см. fsck.<msg-id>) и потенциальные проблемы безопасности, такие как наличие каталога .GIT или вредоносного файла .gitmodules (см. Примечания к выпуску для v2.2.1 и v2.17.1 для деталей). Другие проверки работоспособности и безопасности могут быть добавлены в будущих версиях.
На принимающей стороне сбой fsckObjects сделает эти объекты недоступными, см. «КАРАНТИННАЯ СРЕДА» в git-receive-pack [1] . Со стороны извлечения, неправильно сформированные объекты будут оставлены без ссылки в хранилище.
Если вы можете отключить receive.fsckObjects (и / или если он установлен, transfer.fsckObjects, но связанное с ним уведомление GitLab предполагает, что они просто всегда устанавливают receive.fsckObjects), вы можете открыть себя для потенциальных уязвимостей 2 и, следовательно, подтолкнуть этот некорректный репозиторий вперед. Или, если вы можете установить receive.fsck.skipList, вы можете перечислить эти три конкретных искаженных объекта tree, чтобы GitLab мог продолжать поиск потенциальных уязвимостей, пока вы заявляете, что эти три дерева безвредны. Или, если вы можете установить fsck.zeroPaddedFilemode ignore или receive.fsck.zeroPaddedFilemode ignore, это тоже решит проблему.
Независимо от того, можете ли вы их установить, я понятия не имею: если бы вы могли напрямую войти в gitlab.com, вы могли бы cd в свой собственный репозиторий и запустить git config, но, очевидно, вы не можете. Ваш последний вариант - убедить каждого, кто использует хранилище robbyrussel, исправить свое хранилище новым исправленным. Это, однако, болезненно для всех остальных.
1 Демонстрация здесь подозрительна: git cat-file -p нормализует вывод дерева, так что это на самом деле не показывает проблему. git cat-file tree <hash> получает необработанные данные, но дерево полно двоичных данных (переменной длины!) И поэтому его трудно наблюдать.
2 Фактический риск здесь довольно низок: уязвимы только старые версии Git, а не версии самого GitLab. Что GitLab делает здесь, так это то, что, по сути, Мы храним только репозитории высочайшего качества, а не те, что содержат хитрые вещи, которые, насколько нам известно, могут быть там, чтобы взломать ваш компьютер, когда вы клонируете репозиторий. Если вы используете последние версии Git, вы, вероятно, также не уязвимы, поэтому защита, которую GitLab продает вам здесь, - это то, что у вас уже есть. Но если вы используете старые хитрые версии Git, вы можете купить защиту GitLab вместо того, чтобы обновлять свой старый хитрый Git.