Права доступа к файлам распределяются между ветками git

Question

Не уверен, почему это происходит, но проблема в том, что я изменяю права доступа к файлу в ветке после того, как я перенес эту ветку на удаленный. Затем я извлекаю новую ветку из нашей ветки интеграции, и у нее есть разрешения от "мертвой ветки", вот как это происходит:

# on feature branch
git checkout --no-track -b foo
git reset --soft "remotes/origin/dev"
git add .
git add -A
git commit --allow-empty -am "bar"
git push -u origin foo
chmod -R -w .  # remove all write permissions in current dir

# later on
git branch --no-track z "remotes/origin/dev"
git checkout z
### ughh this new branch z files are not writable, but whyyyy?

в основном мы изменили файлы на недоступные для записи, и эта ветвь никогда не объединяется с какой-либо веткой - мы передали ее на удаленный компьютер перед изменением прав доступа к файлу.

Почему права доступа к файлам без записи отображаются в других ветвях, которые никогда не объединялись с веткой файлов без записи?

Answer 1

Единственные разрешения, которые Git заботит и сохраняет для каждого файла, - это разрешение «является или не является исполняемым». TL; DR для этого поведения chmod - «не делай этого» - вместо этого используйте для этого отдельные клоны или отдельные рабочие деревья. Подробнее читайте в.

В частности, в каждом снимке фиксации каждый файл (или blob , на самом деле) помечается как режим 100644 (не исполняемый) или 100755 (исполняемый). Вы увидите это в выводе git ls-tree, как и при любом существующем коммите. Все другие разрешения, включая возможность чтения или записи, остаются за вами. В Unix и Unix-подобных системах, когда Git создает файл рабочего дерева, он фактически использует либо режим 0777 (если файл должен быть исполняемым), либо 0666 (если нет). Ваш umask лишает вас всех нежелательных разрешений; типичные значения umask: 022 (удалить группу и другие разрешения на запись) или 002 (удалить только не-групповые / другие разрешения на запись), но защищенные подсистемы могут использовать 077 (например, удалить все группы и другие разрешения) .

Обратите внимание, что Git имеет возможность хранить данные внутреннего репозитория для групповой записи, но это не файлы рабочего дерева: они в основном влияют на каталоги, в которых Git хранит свободные и упакованные объекты, ссылочные значения , и тому подобное. Они управляются настройкой core.sharedRepository; см. git config документацию . (Помните, что возможность создавать и удалять файлы в каталоге определяется разрешением текущего идентификатора пользователя и группы на запись в самом каталоге. Ну, то есть, если вы не включите ACL; тогда это становится серьезно сложным.)

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