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

229

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

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

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

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

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

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

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

Сэм Эллиотт
источник

Ответы:

142

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

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

* text=auto

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

adnans
источник
5
Спасибо! Я наконец нашел это после того, как провел весь вечер, переключая core.autocrlf и apply.whitespace. Это сработало. Спасибо.
xer0x
5
Оскорбительная строка в .gitattributes пришла из точечных файлов Матиаса Бинена, на случай , если кто-нибудь еще столкнется с этим.
SeanPONeil
31
Кто-нибудь может пролить больше света на эту конкретную конфигурацию? Что делает * text=auto? Что это значит удалить из .gitattributes? Я вижу, что это решает эту проблему для меня, но я не уверен, почему это так, и что он действительно делает, и какие возможные проблемы это может создать?
Деннис
6
@Dennis Этот параметр помогает нормализовать окончания строк, поэтому удаление его, вероятно, не правильный ответ. См этого вопроса «s ответа и эта статья . Ответ @Arrowmaster ниже был более полезным для меня. Я использовал git addи git commitкоторый нормализовал файл и избавился от проблемы.
Jtpereyda
4
git config --global core.autocrlf inputисправил это для меня. Спасибо.
dimiguel
89

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

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

Сэм Эллиотт
источник
Они когда-нибудь разбирались? Возможно, у меня та же проблема.
Джош Джонсон
8
Да, просто попросите кого-нибудь с файловой системой, чувствительной к регистру, удалить все, кроме одного, из каждого набора файлов, которые будут иметь повторяющиеся имена файлов в файловой системе без учета регистра.
Сэм Эллиотт
1
Просто столкнулся с той же проблемой после перехода с Ubuntu на Mac. Спасибо, твой ответ ударил ногтем по голове. Надеюсь, что голос подтолкнет его к первой позиции. :-)
chmac
1
@ Дирк, вот почему есть несколько ответов. Я принял тот, который применяется в моем случае, что не является необоснованным.
Сэм Эллиотт
1
Это была и моя проблема - MacOS без учета регистра. Однако git ls-tree HEAD <path>показал только один файл. Однако я смог увидеть дубликаты файлов в пользовательском интерфейсе GitHub.com, а также использовать этот интерфейс для удаления одной версии.
orion elenzil
74
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, если это необходимо, при создании хранилища.

Петр Корлага
источник
2
Но что это делает ??
Сивел
1
Я также хотел бы знать, что это делает, потому что это сработало и для меня.
Донато
2
Когда я это сделал git diff, я обнаружил, что изменения были только в файловом режиме. git обнаруживает, chmod -R 777 .что было вызвано, когда я запускал свой проект, и этот конфиг позволял мне игнорировать изменения chmod с помощью git stackoverflow.com/q/1580596/6207775
Ayushya
1
Ссылка не работает ( «Извините, мы не можем найти ваши ядра» ).
Питер Мортенсен
Остальные ответы не сработали, однако это сделало волшебство!
Познакомьтесь с Патель
53

Я предполагаю, что вы используете 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
Arrowmaster
источник
8
Я не использую Windows.
Сэм Эллиотт
1
По умолчанию в системах, отличных от Windows, core.autocrlf имеет значение false. Таким образом, вы не должны были даже столкнуться с этой проблемой, если она вызвана окончанием строки. Не могли бы вы дать более подробную информацию о вашей конкретной настройке, например, что git diffпоказывает для тех файлов, которые git statusговорят, что изменены, а также какую файловую систему вы используете?
Arrowmaster
обновил вопрос с ответами на эти вопросы. Еще раз рассмотрим все детали в секунду или две. Я не уверен, что используют другие члены команды разработчиков
Сэм Эллиотт
Это то, что у нас сработало (git config core.autocrlf false было достаточно). Нас обманул тот факт, что клиент работает в Linux (SL / RHEL), но сеанс Linux инициируется через x2go с хоста Windows. Так что это вполне может быть наиболее вероятным решением в однородном контексте Win + Lin.
Дирк
37

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

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

# Write both the index and working directory from git's database.
git reset --hard
KDS
источник
Ни одно из других решений не помогло мне, но это вернуло меня к работе.
rainabba
1
Я попробовал это, и это сработало для меня. Спасибо, господин Ляма!
Данниэль Литтл
Это делает мой репозиторий хуже. На ветке без изменений у меня было 277 после запуска. У меня были те же изменения в других ветках, на которые я тоже переключился. Беги с осторожностью. Я только что отреагировал на репо и изменил 615 файлов. :(
программист Пол
у меня это работало с использованием git v2.7.4 с ubuntu (WSL), Git для Windows v2.18.0.windows.1 и posh-git. У меня всегда было autocrlf false, и проблема началась в Git для Windows и posh-git после обновления до 2.18.0 сегодня
Джим Френетт
Я поражен, что это работает. Спасибо за помощь. Для других, кто шел по этому пути, все файлы, которые, казалось бы, были модифицированы, были файлами .png и .bmp, управляемыми git LFS
Дэвид Каспер
16

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

* text=auto

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

Дж. Адам Роджерс
источник
1
Спасибо, боролся с этим для aaaages
Эндрю Берри
Это была именно моя проблема. Другой разработчик использовал GIT через VS вместо CLI и создал этот файл .gitattributes.
Джош Мааг
12

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

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

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

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

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑
Gima
источник
5

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

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

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

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

Деннис
источник
4

Та же проблема для меня. Я мог видеть несколько изображений с одним и тем же именем, например «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's database.
git reset --hard

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

# Local Git configuration
git config core.ignorecase = true

или

# Global Git configuration
git config --global core.ignorecase = true
Адриан
источник
Было бы лучше , если бы вы только upvoted@ KDS игрового ответа !
Elharony
Кажется, что команда командной строки не должна иметь знак равенства ( =), потому что она окажется ignorecase = =в файле конфигурации.
Дмитрий
3

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

geoip.dat и GeoIP.dat

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

user2148301
источник
1

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

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

8bitme
источник
1

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

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 config core.Filemode false
Гильермо
1

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

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

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

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

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

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

Лукас Зех
источник
0

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

Олег Швецов
источник
0

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

*.psd binary
Лэнни
источник
0

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

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

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

Томас Эйлотт
источник
0

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

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

Тодд чаффи
источник
1
Было бы полезно (и интересно) узнать, какие версии git не играют вместе.
jpaugh