Git відмовляється скидати / відкидати файли


76

У мене є проект із певними файлами js, які я не можу оновити. Я запускаю OSX локально, і моїм віддаленим / проміжним сервером є Linux (CentOS).

Відразу після клонування мого проекту локально, я помітив, що у мене є всі ці файли зі статусом git modified. Я ніколи їх не модифікував, тому намагався discard changesабо resetїх, але вони з’являються знову. Зміною, яка є в модифікації, є видалення всіх рядків та додавання їх знову.

Я не впевнений, чому це відбувається або як це виправити, щоб мій статус git був чистим, як це потрібно.

Ось кілька рядків зі статусу git:

#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/el.js
#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/fa.js
#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/gu.js

ОНОВЛЕННЯ 1:

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

error: Your local changes to the following files would be overwritten by merge:
    app/webroot/js/ckeditor/_source/lang/ar.js
    app/webroot/js/ckeditor/_source/lang/bg.js
    app/webroot/js/ckeditor/_source/lang/bn.js
    app/webroot/js/ckeditor/_source/lang/cs.js
    ...
Aborting

Я не можу зафіксувати / натиснути, оскільки

Updates were rejected because a pushed branch tip is behind its remote counterpart

Я намагався:

git reset --hard

і

git stash
git stash drop

Але вони не працюють, нічого не відбувається.

ОНОВЛЕННЯ 2:

git diff дає мені:

The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in app/webroot/js/ckeditor/_source/lang/fa.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in app/webroot/js/ckeditor/_source/lang/gu.js.
The file will have its original line endings in your working directory.
...

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

Ні, немає. Він показав би лише 1 зміну рядка на відміну від усіх рядків. Крім того, якщо відбулися якісь реальні зміни, я мав би змогу їх відкинути, що в даному випадку це не працює.
mgPePe

Відповіді:


105

Нормалізувати закінчення рядків

Зміною, яка є в модифікації, є видалення всіх рядків та додавання їх знову.

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

У Github є зручна сторінка, де описано, як боротися з подібною проблемою, коротко (для Linux / OSX), крок перший - змінити конфігурацію git, щоб вона відсортувала для вас закінчення рядків:

git config --global core.autocrlf input

Потім виконайте нормалізацію закінчень рядків:

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

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

git add .
# Prepare to make a commit by staging all the files that will get normalized.
# This is your chance to inspect which files were never normalized. You should
# get lots of messages like: "warning: CRLF will be replaced by LF in file."

git commit -m "Normalize line endings"
# Commit

І тоді, закінчення рядків слід обробляти правильно. Для отримання додаткової інформації див. Сторінку довідки на github або відповідний розділ форматування та пробілів git docs .

Вирішення конфліктів Linux-машина

проміжний сервер заблоковано, оскільки він не спричинить нових змін.

У повідомленні про помилку написано "Ваші локальні зміни в наступних файлах будуть замінені шляхом злиття:", це означає, що вони містять локальні зміни, які слід або скопіювати, або відкинути, перш ніж продовжувати. Припускаючи нормальне використання для проміжного сервера (він не має жодних навмисних змін), локальні зміни можна відкинути. Наприклад, зробіть наступне:

$ git fetch origin
# Retrieve updates

$ git reset --hard origin/master
# Forcibly change the current branch to match origin/master

Це дозволить отримати історію сховища, не оновлюючи робочу копію, а потім оновити, щоб точно відповідати головній гілці у сховищі. Зауважте, що остання команда відхилить усі незафіксовані зміни.


Дякую! Така повна відповідь, і ви подбали про конфлікт вчинення!
mgPePe

1
Ви тільки що врятували мене за день.
Джеррі Брейді,

Я отримую подібну проблему, але з зображеннями. Як ви думаєте, чи було б це пов’язано з цією відповіддю?
Буде

Можливо - яка різниця: закінчення рядків, виконуваний файл чи щось інше? Для будь-якої відповіді, окрім "так, це було" -> задайте питання, що стосується цього. Відповідна різниця, якщо є різниця, полягає в тому, що файли зображень є двійковими і тому на них не повинно впливати будь-яке пов'язане із закінченням рядка.
AD7six

1
У нас була добросовісна команда підрядників, яка додала атрибути .gitatt із увімкненими нормалізаціями, що закінчують рядки. Це спричинило плутанину для розробників, коли вони не могли змінити гілки, оскільки це пошкоджує індекс. Ця відповідь допомогла нам очистити кеш і відновити індекс (git rm --cached -r. І git reset --hard), але найкращим рішенням для нас було взагалі видалити .gitattributes, щоб все працювало так, як це було до того, як вони змінив його.
неописати

15

Я завжди згадував про те, щоб переконатися, що для вашого core.autocrlfвстановлено значення false, як у " Git: застряг репо за допомогою схованки після нормалізації crlf? "

git config --global core.autocrlf false

Також переконайтеся, що у вас немає .gitattributesфайлу з eolдирективами, які намагаються перетворити кінець рядків.
Основна ідея: чи все ще ви бачите це повідомлення про помилку, переконуючись у відсутності будь-якого автоматичного перетворення?


Але про всяк випадок розгляньте також " Git rebase не вдається," Ваші локальні зміни до наступних файлів будуть замінені шляхом злиття ". Немає локальних змін? "

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

git config --global core.trustctime false

2
хороша порада. Найбільш доцільно, якщо немає користувачів Windows, які співпрацюють для створення нових рядків, або якщо проблеми виникають лише у файлах постачальників. Однак якщо є змішана команда користувачів Windows + Mac / Linux - це призведе до постійних змін пробілів залежно від того, хто торкнувся файлу останнім. +1.
AD7six

1
Дякуємо за інформацію .gitattributes . Не знав про це. У моєму випадку це було причиною того, що я не міг відкинути зміни. Тепер проблема вирішена!
informatik01

1
Це був мій файл .gitattributes з eol. Дякую!
JohnnyFun

10

Я просто витратив 2 години (!) На те саме питання з файлом .svg (Scalar Vector Graphics), який постійно змінювався після "повернення" без мого втручання.

Отже, файл відображається як змінений у "git status" ; повернути це вдається, але воно постійно змінюється, тому «тяга» знову і знову не вдається .... так дратує!

Не пощастило з 'git reset' , 'git ignore' , 'git untrack' тощо ...

Нарешті, я вирішив це, видаливши файл з моєї локальної системи (не 'git delete' , просто Shift + Delete) >> тепер проходить запит 'pull' , і файл отримується з віддаленого сховища.

Так легко, я міг плакати!


1
Цікавий альтернативний підхід. +1
VonC

Це відповідь, якщо ви застрягли, тому що перевіряєте минулий коміт (це означає, що ви не можете додати
коміт,

1
Безумовно, це найпростіше рішення для мене. Дякую.
Nersoh

5

Ця проблема неодноразово виникала у сховищі аркушів символів Roll20 на машині Ubuntu, і я міг її вирішити

#!/bin/sh

# Use in root dir of git repository
# Fixes some newline-related weirdness
git rm --cached -r .
git reset --hard

Але це зупинило вирішення проблеми повністю сьогодні, і, оглянувши переповнення стека, я виявив винуватцем їх .gitattributesфайл:

# Auto detect text files and perform LF normalization
* text=auto

Після git pull origin master, git statusповернуто:

On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Star Wars Revised RPG/SWRRPG-updated.html

no changes added to commit (use "git add" and/or "git commit -a")

Рішенням було видалити * text=autoрядок із .gitattributes:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   .gitattributes

no changes added to commit (use "git add" and/or "git commit -a")

Зміни на .gitattributes можна відкинути, і Git все одно буде задоволений.

Редагувати + 1d : Спробував сьогодні "фокус" .gitattributes, але git statusраніше не відміняв зміни .gitattributes. З жодної очевидної для мене причини (можливо кешування git status?), git statusЗгодом це знову повернулося:

On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Star Wars Revised RPG/SWRRPG-updated.html

no changes added to commit (use "git add" and/or "git commit -a")

Повторюю це знову, але з git statusпроміжком часу працювало.


Гарно задокументовано. +1
VonC
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.