Файлы, отображаемые как измененные сразу после клона Git - PullRequest
216 голосов
/ 15 февраля 2011

У меня сейчас проблема с репозиторием, и хотя мой Git-fu обычно хорош, я не могу решить эту проблему.

Когда я клонирую этот репозиторий, тогда cd в хранилище, git status показывает несколько файлов, которые были изменены.Примечание. Я не открыл хранилище ни в каком редакторе или в любом другом месте.

Я пытался следовать этому руководству: http://help.github.com/dealing-with-lineendings/,, но это не помогло с моей проблемой.

Я пытался git checkout -- . много раз, но, похоже, ничего не делал.

Я на Mac, и в самом хранилище нет подмодулей.

Файловая система"Журналированная файловая система HFS +" на Mac и не чувствительна к регистру.Файлы состоят из одной строки и около 79 КБ каждый (да, вы правильно поняли), поэтому просмотр git diff не особенно полезен.Я слышал о выполнении git config --global core.trustctime false, которое может помочь, которое я попробую, когда вернусь к компьютеру с репозиторием.

Я изменил детали файловой системы с фактами!И я попробовал трюк git config --global core.trustctime false, который не очень хорошо работал.

Ответы [ 17 ]

137 голосов
/ 28 апреля 2012

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

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

* text=auto

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

87 голосов
/ 17 февраля 2011

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

Я получу один из них, чтобы разобраться.

60 голосов
/ 02 июля 2015
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, если необходимо, при создании хранилища..

52 голосов
/ 16 февраля 2011

Я предполагаю, что вы используете 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
34 голосов
/ 17 апреля 2015

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

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

# Write both the index and working directory from git's database.
git reset --hard
16 голосов
/ 25 октября 2013

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

* text=auto

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

12 голосов
/ 14 мая 2014

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

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

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

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

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑
4 голосов
/ 27 февраля 2014

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

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

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

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

3 голосов
/ 21 октября 2013

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

geoip.dat и GeoIP.dat

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

2 голосов
/ 22 ноября 2018

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

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

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

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

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

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

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

# Local Git configuration
git config core.ignorecase = true

или

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