Файлы, отображаемые как измененные непосредственно после клонирования git

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

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

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

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

любая помощь/идеи будут с благодарностью

Update 1: я на mac, и в самом РЕПО нет подмодулей.

Update 2: файловая система " Journaled HFS+" файловая система на mac, и не чувствительна к регистру. Файлы однострочные и около 79K каждый (да, вы слышали правильно) , поэтому смотрите на git diff не особенно полезно. Я слышал о делаем git config --global core.trustctime false что может помочь, что я попробуйте, когда я вернусь к компьютеру с РЕПО на нем.

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

14 ответов


у меня была такая же проблема на Mac после клонирования РЕПО, было бы предположить, что все файлы были изменены.

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

* text=auto

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


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


git config core.fileMode false

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

https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html

TL; DR;

ядра.содержит filemode

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

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


Я предполагаю, что вы используете Windows. Эта страница github, которую вы связали, имеет детали назад. Проблема в том, что окончание строки CRLF уже было зафиксировано в репо и потому что у вас есть ядра. значение правда или вход, git хочет преобразовать окончания строк в LF so git status показывает, что каждый файл изменился.

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

git config core.autocrlf false


Если это РЕПО, в котором вы будете активно участвовать и можете вносить изменения. Вы можете решить проблему, сделав фиксацию, которая изменяет все окончания строк в репо, чтобы использовать LF вместо CRLF, а затем предпринять шаги, чтобы предотвратить ее повторение в будущем.

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

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, перед запуском git add -u.

manual.pdf      -text

и наоборот, текстовые файлы, которые git не обнаруживает, могут иметь нормализацию вручную.

weirdchars.txt  text

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

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

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

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

* text=auto

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


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

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

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

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

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

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

geoip.dat и GeoIP.dat

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


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

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

в моем случае файлы на главной ветви GitHub имели \r\n конец. Я набрал настройки на репо, чтобы зарегистрироваться с \n конец. Я не знаю, что git проверяет. Предполагается проверить с родными окончаниями на мой Linux box (\n), но я думаю, он проверил файл с \r\n конец. ГИТ жалуется, потому что он видит, извлечено \r\n окончания, которые были в репо и предупреждает меня, что он будет проверять в \n настройки. Следовательно, файлы "должны быть изменены".

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


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

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


редактировать файл с названием: sudo gedit .git/config sudo vim .git/config

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = kharadepramod@bitbucket.org: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


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


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

*.psd binary

у меня была аналогичная проблема и нашел этот вопрос.

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

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

бум! Чистое РЕПО. Проблема решена. Тогда мне просто пришлось отказаться от последнего коммита, когда я сделал свой rebase -i и, наконец, все было чисто снова. Странно!

но я добавляю это решение здесь, так что, возможно, если я когда-нибудь столкнусь с этим снова, я увижу это и попробую. Спасибо :D