Как удалить файлы с надписью "старый режим 100755 новый режим 100644" из неустановленных изменений в Git?
По какой-то причине, когда я изначально извлекал данные из своего репозитория для моего git-проекта, я получил тонну файлов в моей рабочей копии, в которых не было внесено каких-либо заметных изменений, но они постоянно появляются в моем unstaged changes площадь.
Я использую Git Gui на Windows XP, и когда я иду, чтобы посмотреть файл, чтобы увидеть, что изменилось. Все, что я вижу, это:
old mode 100755
new mode 100644
Кто-нибудь знает что это значит?
Как я могу вытащить эти файлы из моего списка неповрежденных изменений? (Очень раздражает, что приходится просматривать сотни файлов, просто чтобы выбрать файлы, которые я недавно отредактировал и хочу зафиксировать).
19 ответов
Это похоже на режим доступа к файлам в Unix (755знак равноrwxr-xr-x, 644знак равноrw-r--r--) - старый режим включал флаг +x (исполняемый), новый режим - нет.
Ответы этой проблемы msysgit предлагают установить для core.filemode значение false, чтобы избавиться от проблемы:
git config core.filemode false
Установка для core.filemode значения false работает. Но вы должны убедиться, что настройки в ~/.gitconfig не будут переопределены параметрами в.git/config.
Обычно происходит, когда репо клонируется между компьютерами Windows и Linux/Unix.
Просто скажите git игнорировать изменение файлового режима, вот несколько способов:
Конфигурация ТОЛЬКО для текущего репо:
git config core.filemode falseКонфиг глобально:
git config --global core.filemode falseДобавьте в ~/.gitconfig:
[core] filemode = false
Просто выберите один из них.
Я столкнулся с этой проблемой, когда пару раз копировал git-репозиторий с рабочими файлами со старого жесткого диска. Проблема связана с тем, что владелец и права доступа изменились со старого диска / машины на новый. Короче говоря, выполните следующие команды, чтобы исправить ситуацию ( благодаря этому ответу суперпользователя):
sudo chmod -R -x . # remove the executable bit from all files
Первая команда на самом деле разрешит различия, о которых сообщает git diff, но лишит вас возможности перечислять каталоги, поэтому ls ./ не удается с ls: .: Permission denied, Чтобы это исправить:
sudo chmod -R +X . # add the executable bit only for directories
Плохая новость заключается в том, что если у вас есть какие-либо файлы, которые вы хотите сохранить исполняемыми, такие как .sh сценарии, вам нужно будет отменить их. Вы можете сделать это с помощью следующей команды для каждого файла:
chmod +x ./build.sh # where build.sh is the file you want to make executable again
Я столкнулся с той же проблемой. И это спасет мою жизнь: https://gist.github.com/jtdp/5443498
git diff -p -R --no-color \
| grep -E "^(diff|(old|new) mode)" --color=never \
| git apply
Это сработало для меня:
git ls-files -m | xargs -L 1 chmod 644
Принятый ответ для набора git config core.filemode false, работает, но с последствиями. Настройкаcore.filemodeЗначение false указывает git игнорировать любые изменения исполняемого бита в файловой системе, поэтому он не будет рассматривать это как изменение. Если вам действительно нужно выполнить изменение исполняемого бита для этого репозитория в любое время в будущем, вам придется сделать это вручную или установитьcore.filemode назад к истине.
Менее последовательная альтернатива, если все измененные файлы должны иметь режим 100755, - это сделать что-то вроде
chmod 100755 $(git ls-files --modified)
который просто меняет режим, не больше и не меньше, без дополнительных последствий.
(в моем случае это произошло из-за синхронизации OneDrive с моей файловой системой в MacOS; не меняя core.filemode, Я оставляю возможность, что изменение режима может произойти снова в будущем; в моем случае, я хотел бы знать, произойдет ли это снова, и изменивcore.filemode скроет от меня, чего я не хочу)
Вы можете попробовать git reset --hard HEAD, чтобы вернуть репо в ожидаемое состояние по умолчанию.
Это решение изменит права доступа к файлу git с 100755 на 100644 и вернет изменения обратно в удаленное репо битбакета.
Взгляните на права доступа к файлу вашего репо: git ls-files --stage
Если 100755 и вы хотите 100644
Затем запустите эту команду: git ls-files --stage | sed 's / \ t / / g' | вырезать -d '' -f4 | xargs git update-index --chmod=-x
Теперь снова проверьте права доступа к файлу вашего репо: git ls-files --stage
Теперь зафиксируйте свои изменения:
git статус
git commit -m "восстановил правильные права доступа к файлам"
git push
Кажется, вы изменили некоторые разрешения каталога. Я сделал следующие шаги, чтобы восстановить его.
$ git diff > backup-diff.txt ### in case you have some other code changes
$ git checkout .
Это происходит, когда вы извлекаете и все файлы были исполняемыми в удаленном хранилище. Если снова сделать их исполняемыми, все снова станет нормальным.
chmod +x <yourfile> //For one file
chmod +x folder/* // For files in a folder
Вам может понадобиться сделать:
chmod -x <file> // Removes execute bit
вместо этого для файлов, которые не были определены как исполняемые и которые были изменены из-за вышеуказанной операции. Есть лучший способ сделать это, но это очень быстрое и грязное исправление.
Вы можете использовать следующую команду, чтобы изменить режим файла обратно.git add --chmod=+x -- filenameТогда зафиксируй ветку.
Это похоже на то, что нашел bkm, но он также учитывает все удаленные файлы и выдает предупреждение только при применении изменений.
Это хорошо работает для возврата настроек режима файла из предыдущей фиксации.
git diff -p --no-ext-diff --no-color --diff-filter=d | grep -E "^(diff|old mode|new mode)" | sed -e "s/^old/NEW/;s/^new/old/;s/^NEW/new/" | git apply
Ряд приведенных выше решений сломается, если есть какие-либо удаленные файлы.
Это отобразит файлы, которые только изменены, а не удалены, и изменит их все на
755
git diff-files --name-only --diff-filter=d | xargs -L 1 chmod 755
Запустите git из WSL2 для полной совместимости с Linux, и тогда вам не придется использовать обходные пути, такие как переключение core.filemode до и после фиксации.
У меня был только один проблемный файл с измененными разрешениями. Чтобы откатить его по отдельности, я просто удалил его вручную rm <file> а затем сделал проверку, чтобы вытащить свежую копию.
К счастью, я еще не поставил это.
Если бы я имел, я мог бы бежать git reset -- <file> перед запуском git checkout -- <file>
Если вы разрабатываете в Windows в Linux-контейнере разработки, используя одну и ту же версию папки для Windows и WSL, вы можете предпринять следующие шаги:
Отключите файловый режим в локальной области репозитория (т. е. запустите эту команду из иерархии папок репо):
git config --unset --local core.fileModeВ Windows установите для файлового режима значение false в глобальной области (т. е. запускайте из любого места в Windows):
git config --global core.filemode falseВ контейнере установите для файлового режима значение true в глобальной области видимости (т. е. запускайте из любого места контейнера):
git config --global core.filemode true
Теперь вы не увидите измененные файлы, содержимое которых не изменилось.
Кроме того, вы можете внести это изменение в файл devcontainer.json.postCreateCommandпараметр, чтобы он сохранялся при перестроении контейнера.
Я только столкнулся с этой проблемой, когда сравнивал мою ветку с мастером. Git вернул одну ошибку 'mode', когда я ожидал, что моя ветвь будет идентична master. Я исправил, удалив файл, а затем снова включил мастер.
Сначала я запустил diff:
git checkout my-branch
git diff master
Это вернулось:
diff --git a/bin/script.sh b/bin/script.sh
old mode 100755
new mode 100644
Затем я запустил следующее, чтобы исправить:
rm bin/script.sh
git merge -X theirs master
После этого, git diff не вернул никаких различий между my-branch и master.
Выполните эту команду:chmod 755 xxxзамените «xxx» на путь к файлу, тогда, надеюсь, все пойдет правильно. Команда вернула уровень привилегий с 100644 на 100755.