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

У меня сейчас проблема с хранилищем, и хотя мой 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хитрость, которая не очень хорошо работала.

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

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

* text=auto

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

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

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

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, если это необходимо, при создании хранилища.

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

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

# 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
   ↑↑↑

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

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

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

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

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

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

geoip.dat и GeoIP.dat

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

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

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

Отредактируйте файл с именем .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.

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

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

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

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

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

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

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

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

*.psd binary

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

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

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

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

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