Файлы, отображаемые как измененные непосредственно после клонирования 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 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