Вопрос по chmod, git, file-permissions – Git необъяснимо меняет права доступа к одному файлу

4

Я единственный человек, связанный с этим проектом Git. Каждый раз, когда я редактирую файлы в своем локальном репозитории Ubuntu, затем отправляю их в Bitbucket и извлекаю в производственный репозиторий, git изменяет отредактированные файлы на -rwxrwxr-x 775. Apache не делает 'не нравится это

Локальная система: git версия 1.8.1.2 в Ubuntu Linux

Производственная система: версия git 1.7.12 для CentOS / Red Hat Linux

Когда я фиксирую разрешения на 755, то делаю

git diff

или же

git diff -p

Ничего не показывает

В моем локальном репозитории разрешения 755, и все файлы принадлежат haws. В моем производственном репозитории все остальные разрешения остаются на уровне 755, и все файлы, включая contact.php, принадлежат моему имени пользователя.

Как в локальном, так и в производственном репозитории я изменил core.filemode следующим образом, пытаясь остановить это поведение.

core.filemode = false

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

Что я могу сделать, чтобы увидеть Git 's причина изменения прав доступа к этому файлу?Как я могу заставить git перестать менять его?

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

Мое окончательное решение (спасибо VonC 'руководство):

Благодаря VonC 'хорошее объяснение, я был достаточно смел, чтобы понять, что каждый раз, когда я заходил на свой сервер, мой umask возвращался к 0002. Поэтому я создал скрипт запуска пользователя (.bashrc или, в моем случае, .bash_profile) на моем хосте Linux это устанавливает

Umask 0022

или используя символическую запись (для небольшой добавленной стоимости)

umask u=a,g-w,o-w 

или же

umask u=a,go-w 

(Разрешить все разрешения для пользователя, запретить права на запись для группы и других)

Это решило мою проблему.

Ранее я установил в git config core.sharedRepository значение true, но это не моя проблема, и я удалил этот параметр, как только проблема была решена.
Смотрите комментарий 16 октября 2009stackoverflow.com/questions/1580596/...           Также это может быть связано с тем, как вы добавляете файлы в рабочее дерево (git add. Vs git commit -a) spuder
Я предлагаю упомянуть вашу операционную систему и версию git для лучшего и более четкого ответа. Здесь есть различия в отношении окон и не оконных систем. Arafangion
Превращение core.filemode в false, вероятно, неплохой обходной путь. И возможно этотоже не плохая стандартная практика рабочего процесса. Тем не менее, яХотелось бы узнать, почему Git не "работает как рекламируется, Что я пропускаю? Tom Haws
Спасибо. Делать, как вы предложили. Tom Haws
Также смотрите вопросstackoverflow.com/questions/10657513/... для дополнительной информации. andygavin

Ваш Ответ

1   ответ
7

Как уже упоминалось вНеправильное разрешение файла при использовании git pull in hook

Git не хранит разрешения,кроме исполняемого бита.

Итак, при оформлении заказа файлы создаются с разрешениями по умолчанию, которые зависят от вашегоUmask.

В твоем случае:umask 0022 должен быть установлен, когда вы тянете.

(это то, что я упоминал в ответе, который вы видели "Запретить Git изменять права на pull ")

Это предполагает, что у вас есть в целевом хранилище такая конфигурация:

git config core.sharedRepository true

Другое решение упоминается в "Как я могу поделиться репозиторием Git с несколькими пользователями на машине? ", где вы должны убедиться в том, что инициализируется репо:

git init --shared=0022

ОПТом Хоуз добавляет в комментариях:

Ты знаешь почему мерзавец у моего клиентаРабочий сервер может работать без изменения прав доступа к файлам, даже если нетsharedRepository запись в этом хранилище »с конфиг?

Может быть, потому что umask был установлен по умолчанию0022 уже означает, что по умолчанию оболочка git наследуетumask системы.

Изменениеumask требуетcore.sharedRepository установлен вtrue принять это во внимание вместо того, чтобы приниматьumask родительского процесса.

Это, или потому что репо был создан с.--shared=0022

Чтобы увидеть, какumask можно установить (для всей системы или для пользователя), см. "Как настроить систему в целом?umask

Чтобы проверитьumask непосредственно перед командой git (которая унаследует ее значение) просто введите:

umask
Я отредактировал свой вопрос, чтобы показать свое окончательное решение, которому ты меня научил. Tom Haws
@ Tomomaws идея в том, что еслиcore.sharedRepository установлен в true, тогда git будет уважатьumask когда тянет. мерзавец несменить umask (но он может игнорировать его, еслиcore.sharedRepository установлен вfalse или не установлен вообще). VonC
@ TomHaws Может быть, потому чтоumask по умолчанию было установлено0022 уже (это означает, что по умолчанию оболочка git наследуетumask системы. Изменениеumask требуетcore.sharedRepository быть установленным в true, чтобы принять его во внимание вместо использования umask родительского процесса). Это, или потому что репо был создан с.--shared=0022 VonC
2. Я добавил git config core.sharedRepository true. Это решило мою проблему. Я прочитаю об этом. Благодарю. Я'Я принимаю ваш ответ и надеюсь, что вы еще немного побеседуете со мной, чтобы помочь мне понять, что происходит. Причина, по которой я все еще в замешательстве, заключается в том, что я неПонять, как в этом случае применяется sharedRepository. Это потому чтоHaws» владеет файлами на моем локальном сервере иjconstru» владеет ими на производственном сервере? Tom Haws

Похожие вопросы