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

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

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

* text=auto

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

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 уже было зафиксировано в репо, и потому что у вас есть ядра. значение правда или input, 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, снимите их атрибут text перед запуском 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 и .файлов 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 путем к файлу и имени файла. Чтобы решить эту проблему, клонируйте РЕПО как можно ближе к корню жесткого диска, чтобы уменьшить длину пути к файлу, например, клонировать его C:\A\GitRepo вместо того, чтобы C:\Users документы\yyy\Desktop\GitRepo

редактировать файл с названием: sudo gedit .git/configsudo 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

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

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

*.psd binary

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

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

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

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

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