it-swarm-ru.tech

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

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

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

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

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

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

Обновление 1: я на Mac, и в самом репо нет подмодулей.

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

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

206
Sam Elliott

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

Я возьму одного из них, чтобы разобраться.

84
Sam Elliott

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

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

* text=auto

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

135
adnans
git config core.fileMode false

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

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

TL; DR;

core.fileMode

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

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

57
Piotr Korlaga

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

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

git config core.autocrlf false


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

Следующая информация взята непосредственно из справочной страницы 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, удалите их текстовый атрибут перед запуском git add -u.

manual.pdf      -text

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

weirdchars.txt  text
51
Arrowmaster

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

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

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

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

* text=auto

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

15
J Adam Rogers

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

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

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

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

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

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

geoip.dat и GeoIP.dat

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

3
user2148301

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

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

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

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

3
Dennis

Редактировать файл с именем: 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

1
Pramod Kharade

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

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

1
8bitme

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

0
Oleg Shvetsov

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

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

0
Todd Chaffee

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

или же 

# Global Git config
git config --global core.ignorecase = true
0
Adrian

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

*.psd binary
0
Lanny

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

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

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

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

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

0
Lukas Zech

У меня была похожая проблема, и я нашел этот вопрос.

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

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

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

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

0
Thomas Aylott