Файли, що відображаються як модифіковані безпосередньо після клонування 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).

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

Я припускаю, що ви використовуєте Windows. Ця сторінка GitHub, на яку ви пов’язали, має деталі назад. Проблема полягає в тому, що закінчення рядків CR + LF були записані в сховище і тому, що у вас є core.autocrlf, встановлений на істинний, або на вхідний , Git хоче перетворити закінчення рядків у LF, тому git statusпоказує, що кожен файл змінюється.

Якщо це сховище, до якого ви хочете отримати доступ, але не маєте участі в ньому, ви можете запустити наступну команду, щоб просто приховати проблему, фактично не вирішивши її.

git config core.autocrlf false

Якщо це сховище, до якого ви будете брати активну участь і можете здійснювати зміни. Ви можете вирішити проблему, зробивши зобов’язання, яке змінює всі закінчення рядків у сховищі, щоб використовувати LF замість CR + LF, а потім вжити заходів, щоб у майбутньому це не повторилося.

Далі взято безпосередньо зі сторінки gitattributes man і має бути попередньо оформлено з чистого робочого каталогу.

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 перевіряє. Передбачається перевірка \nфайлів із \r\nвласними закінченнями на моєму вікні Linux ( ), але я думаю, що він перевірив файл із закінченнями. Git скаржиться, бо бачить перевірені \r\nзакінчення, які були у сховищі, і попереджає мене, що він перевіриться в \nналаштуваннях. Отже файли "підлягають модифікації".

Це зараз моє розуміння.

У мене була така ж проблема. Також з Mac. Переглядаючи сховище на машині Linux, я помітив, що у мене є два файли:

geoip.dat і GeoIP.dat

Я видалив застарілий на машині Linux і знову клонував сховище до Mac. Мені не вдалося витягнути, скопіювати, приховати або витягнути зі своєї копії сховища, коли були дублікати.

Те саме питання для мене. У віддаленому сховищі Git я міг бачити кілька зображень з такою ж назвою, як "textField.png" та "textfield.png", але не в моєму локальному сховищі. Мені вдалося побачити лише "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

У мене теж була така ж проблема. У моєму випадку я клонував сховище, і деякі файли одразу були відсутні.

Це було викликано тим, що шлях до файлу та ім'я файлу були занадто довгими для 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'

Бум! Чистий сховище. Проблема вирішена. Тоді я просто повинен був скинути останнє зобов’язання, коли я зробив своє, rebase -iі нарешті все знову було чисто. Химерно!

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

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