Git Gui Отличий не обнаружено

У меня есть репозиторий в Git, где большое количество файлов помечено как редактируемые Git Gui, когда я нажимаю на один из них, появляется диалоговое окно, содержащее:

    "No differences detected.

     filename.h has no changes.

     The modification date of this file was updated by another
     application, but the context within the file has not changed.

     A rescan will be automatically started to find other files which
     may have the stame state."

Если я нажму кнопку «ОК», приложение выполнит повторное сканирование и отобразит точно такие же результаты и бесконечный цикл, потому что любой файл с этим условием представляет такое же диалоговое окно.

Есть ли способ удалить их автоматически из сканирования, игнорируя пробелы?


git git-gui
person SPlatten    schedule 19.08.2019    source источник
comment
Возможно, это поможет stackoverflow.com/a/21754363/114900   -  person msanford    schedule 19.08.2019
comment
@msanford, извини, не лучше   -  person SPlatten    schedule 19.08.2019

Ответы (2)


arrow_upward
4
arrow_downward

Сначала проверьте, установлено ли для вашего git config --global core.autocrlf значение false.

Если нет (или пусто), установите для него значение false, снова клонируйте свой репозиторий Git и проверьте, сохраняется ли графический интерфейс Git в своей оценке.

Само сообщение приходит от "gui / lib / diff.tcl # handle_empty_diff ", просмотр обвинений показывает код возрастом более 10 лет.

По иронии судьбы существует фиксация под названием «git-gui: Избегайте бесконечного цикла повторного сканирования в handle_empty_diff.» (совершить 584fa9c)

Если механизм обновления индекса и git diff не пришли к согласию относительно того, был ли изменен конкретный файл, это может вызвать git-gui вход в бесконечный цикл повторного сканирования индекса, где пустой diff запускает повторное сканирование, которое находит тот же набор измененных файлов и пытается отобразить разницу для первого, который оказался пустым.
Текущий пример возможной точки разногласий - фильтр autocrlf.

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

Другой предлагаемый подход, основанный на предоставлении аргумента --exit-code для git diff, не может быть использован, потому что diff-файлы, похоже, доверяют временным меткам в индексе и возвращают ненулевой код, даже если файл фактически не изменился, что по существу побеждает цель логики автоматического повторного сканирования.

Попробуйте git add --renormalize -- :/.

person VonC    schedule 20.08.2019
comment
Установлено значение false. - person SPlatten; 20.08.2019
comment
Этот файл открыт другим приложением? - person VonC; 20.08.2019
comment
Нет, я просто использовал графический интерфейс Git, это так раздражает, что он вызывает множество файлов в списке неустановленных изменений, и когда они нажимаются, я получаю исходное сообщение в том виде, как оно было опубликовано, а затем оно повторно сканирует. - person SPlatten; 20.08.2019
comment
@SPlatten Какую версию Git вы используете? На какой ОС? Я отредактировал свой ответ. - person VonC; 20.08.2019
comment
git версия 2.22.0.windows.1 в Microsoft Windows [версия 10.0.16299.1268] - person SPlatten; 20.08.2019
comment
@SPlatten Попробуйте Git 2.23 (github.com/ git-for-windows / git / Release / tag / v2.23.0.windows.1) и git add --renormalize -- :/ - person VonC; 20.08.2019
comment
это не совсем мое решение, все равно спасибо - person SPlatten; 20.08.2019
comment
@SPlatten Это просто распакованный архив (_ 1_), у вас есть полный контроль. Адаптируйте свой %PATH% (в текущем сеансе CMD) к упрощенному, просто для тестирования. Не требует установки, изменения реестра или повышения привилегий. - person VonC; 20.08.2019

arrow_upward
0
arrow_downward

Ответ VonC выше исправил эту очень досадную ошибку для меня. Это должно быть приемлемое решение.

Одна из проблем заключалась в том, что я скопировал и вставил git add --renormalize -- :/, который закончился его точкой в ​​конце предложения, например: git add --renormalize -- :/. Я вернулся через час к этому ответу и понял, что я сделал.

Это была полностью моя вина, поскольку его маркер кода был очевиден в ретроспективе.

person Ferd    schedule 15.12.2020