Файлы, отображаемые как измененные сразу после клона Git

Ответ 1

Я понял. Все остальные разработчики работают на Ubuntu (я думаю) и, таким образом, чувствительны к регистру файловых систем. Я, однако, не (как я на Mac). Действительно, у всех файлов были строчные двойники, когда я взглянул на них, используя git ls-tree HEAD <path>.

Я заставлю одного из них разобраться.

Ответ 2

У меня была такая же проблема на Mac после клонирования репозитория. Предполагается, что все файлы были изменены.

После запуска git config --global core.autocrlf input он все еще помечал все файлы как измененные. После поиска исправления я наткнулся на файл .gitattributes в домашнем каталоге, в котором было следующее.

* text=auto

Я прокомментировал это, и любые другие клонированные репозитории отныне работали нормально.

Ответ 3

git config core.fileMode false

решил эту проблему в моем случае

https://git-scm.com/docs/git-config

TL; DR;

core.fileMode

Если false, различия исполняемого бита между индексом и рабочим деревом игнорируются; полезно на сломанных файловых системах, таких как FAT. Смотрите git-update-index (1).

Значение по умолчанию - true, за исключением того, что git-clone (1) или git-init (1) будут проверять и устанавливать core.fileMode false, если это необходимо, при создании хранилища.

Ответ 4

Я предполагаю, что вы используете Windows. Эта страница GitHub, на которую вы ссылаетесь, содержит подробности в обратном направлении. Проблема в том, что окончания строк CR + LF уже зафиксированы в репозитории, а поскольку у core.autocrlf установлено значение true или input, Git хочет преобразовать окончания строк в LF, поэтому git status показывает, что каждый файл изменяется,

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

git config core.autocrlf false

Если это репозиторий, в который вы будете активно вовлечены и сможете вносить изменения. Вы можете решить проблему, сделав коммит, который изменяет все окончания строк в репозитории на использование LF вместо CR + LF, а затем предпринимает шаги, чтобы предотвратить его повторение в будущем.

Следующая информация взята непосредственно из справочной страницы gitattributes и должна быть предварительно сформирована из чистого рабочего каталога.

echo "* text=auto" >>.gitattributes
rm .git/index     # Remove the index to force Git to
git reset         # re-scan the working directory.
git status        # Show files that will be normalized.
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"

Если какие-либо файлы, которые не должны быть нормализованы, отображаются в git status, удалите их текстовый атрибут перед запуском git add -u.

manual.pdf      -text

И наоборот, для текстовых файлов, которые Git не обнаруживает, можно включить нормализацию вручную.

weirdchars.txt  text

Ответ 5

Запустите следующие команды. Это может решить проблему.

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git database.
git reset --hard

Ответ 6

В Visual Studio, если вы используете Git, вы можете автоматически генерировать файлы .gitignore и .gitattributes. Файл сгенерированный автоматически .getattributes имеет следующую строку:

* text=auto

Эта строка находится в верхней части файла. Нам просто нужно было прокомментировать строку, добавив # к ней. После этого все работало, как ожидалось.

Ответ 7

Проблема может также возникнуть из-за различий разрешений файлов, как и в моем случае:

Свежий клонированный репозиторий (Windows, Cygwin):

$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Базовый удаленный репозиторий (Linux):

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Ответ 8

Я хотел добавить ответ, более направленный на "Почему", это происходит, потому что уже есть хороший ответ о том, как это исправить.

Таким образом, .gitattributes имеет параметр * text=auto, который вызывает эту проблему.

В моем случае файлы в главной ветке GitHubs имели \r\n окончания. Я набрал настройки в хранилище для регистрации с \n окончаниями. Я не знаю, что проверяет Git. Предполагается, что на моем компьютере с Linux (\n) заканчиваются нативные окончания, но я предполагаю, что он извлек файл с окончаниями \r\n. Git жалуется, потому что он видит извлеченные окончания \r\n которые были в хранилище, и предупреждает меня, что он проверит настройки \n. Следовательно, файлы "должны быть изменены".

Это мое понимание на данный момент.

Ответ 9

У меня такая же проблема. Также с Mac. Глядя на репозиторий на машине с Linux, я заметил, что у меня есть два файла:

geoip.dat и GeoIP.dat

Я удалил устаревший на Linux-машине и снова клонировал репозиторий на Mac. Я не смог вытащить, зафиксировать, спрятать или вытащить из своей копии хранилища, когда были дубликаты.

Ответ 10

У меня тоже была такая же проблема. В моем случае я клонировал репозиторий, и некоторые файлы сразу исчезли.

Это было вызвано тем, что путь к файлу и имя файла были слишком длинными для Windows. Чтобы решить эту проблему, клонируйте репозиторий как можно ближе к корню жесткого диска, чтобы уменьшить длину пути к файлу. Например, C:\A\GitRepo его в C:\A\GitRepo вместо C:\Users Documents\yyy\Desktop\GitRepo.

Ответ 11

Отредактируйте файл с именем .git/config:

sudo gedit .git/config

Или же:

sudo vim .git/config

содержание

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true

[remote "origin"]
    url = [email protected]:DigitalPlumbing/unicorn-magento.git
    fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
    remote = origin
    merge = refs/heads/master

[branch "productapproval"]
    remote = origin
    merge = refs/heads/productapproval

Измените filemode=true на filemode = false.

Ответ 12

Для новых версий macOS это может быть вызвано функцией безопасности ОС.

В репозитории, над которым я работал, был бинарный файл с типом файла *.app.

Это были только некоторые сериализованные данные, но macOS рассматривает все файлы *.app как приложение, и поскольку этот файл не был загружен пользователем, система сочла его небезопасным и добавила атрибут файла com.apple.quarantine который гарантирует, что файл может не быть выполненным.

Но установка этого атрибута в файле также изменяла файл, и поэтому он отображался в наборе изменений Git без какого-либо способа его возврата.

Вы можете проверить, есть ли у вас такая же проблема, запустив $ xattr file.app.

Решение довольно простое, если вам не нужно работать с файлом. Просто добавьте *.app binary в ваши .gitattributes.

Ответ 13

Та же проблема для меня. Я мог видеть несколько изображений с одинаковыми именами, например "textField.png" и "textfield.png" в удаленном репозитории Git, но не в моем локальном репозитории. Я мог видеть только "textField.png", который не был использован в коде проекта.

Оказывается, большинство моих коллег работают на Ubuntu с файловой системой ext4, а я на Mac с APFS.

Благодаря ответу Сэма Эллиотта, решение было довольно простым. Сначала я попросил коллегу по Ubuntu удалить избыточные версии файлов с заглавными буквами, затем зафиксировать и нажать на удаленный.

Затем я запустил следующее:

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git database.
git reset --hard

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

# Local Git configuration
git config core.ignorecase = true

или же

# Global Git configuration
git config --global core.ignorecase = true

Ответ 14

Я скопировал свой локальный репозиторий в другую папку, и появилось множество измененных файлов. Мое обходное решение было: Я спрятал измененные файлы и удалил тайник. Репозиторий стал чистым.

Ответ 15

Я обнаружил, что Git рассматривал мои файлы (в нашем случае .psd) как текст. Установка его в двоичный тип в .gitattributes решила это.

*.psd binary

Ответ 16

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

git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'

Boom! Чистый репозиторий. Задача решена. Затем мне просто пришлось отбросить последний коммит, когда я сделал rebase -i и, наконец, все снова стало чистым. Bizarre!

Ответ 17

На случай, если это поможет кому-то еще, для этой проблемы может быть другая причина: разные версии Git. Я использовал установленную по умолчанию версию Git на коробке с Ubuntu 18.04 (Bionic Beaver), и все работало нормально, но при попытке клонировать репозиторий с помощью Git в Ubuntu 16.04 некоторые файлы показывались как измененные.

Ни один из других ответов здесь не устранил мою проблему, но обновление версий Git для соответствия в обеих системах решило проблему.