Змінений знак TortoiseGit (накладення піктограми) не оновлюється


75

Я вніс невелику зміну в деякий код, але TortoiseGit відображає його як модифікований (червоний знак оклику), хоча я робив, тягнув, штовхав, але він залишається. Що мені тут робити? Я не бачив цього питання раніше.


Візьміть різницю, ви зможете побачити, що змінилося. Це також може бути випуск оновлення піктограми TortoiseGit
CharlesB

Відповіді:


120

Я припускаю, що ви використовуєте черепаховий git? У мене була проблема раніше, іноді натискання F5виправляє це інший раз, вона просто зникає після того, як черепаха сама повторно синхронізується.

Ось ще одне можливе посилання на виправлення .

Поточне обхідне рішення - убити TGitCache.exe за допомогою диспетчера завдань Windows.


1
Я думаю, що її черепаха - дякую, спробую це. Все, що я зробив, - це скопіювати копію файлу бек-файлу після того, як я вчинив безлад у коді.
Книжник

1
Переконайтеся, що ви насправді внесли зміни. Ви можете побачити, чи має файл локальні модифікації, які спричинять червоний вигук, клацнувши правою кнопкою миші-> tortoiseGit -> «Перевірити наявність змін».
Енді,

3
Голосуйте за вбивство TGitCache.exe. Через кілька секунд він знову почнеться автоматично.
Саша

5
Через 4 роки проблема все ще існує, і все ще не кращий спосіб вирішити проблему, ніж вбивство TGitCache ... Команді TortoiseGit дійсно потрібно вирішити цю проблему. Накладання марні, якщо вони не відображають поточний стан репозиторію.
Томас Левеск,

1
F5 не вирішив проблему, але вбивство TGitCache.exe це вирішило для мене. Голосуючи!
Gabriel Hautclocq

41

Мені допомогло наступне:

  1. Перейдіть до "Налаштування -> Накладання піктограм" Перевірте в розділі "Кеш стану" опцію "немає"
  2. Оновіть провідник F5
  3. Поверніться назад і змініть опцію кешу назад на "За замовчуванням"

3
Це не працює ... повертає неправильний статус, коли вибрано за замовчуванням ... Оновлення: потрібно було "пройтися" по дереву каталогів .. тепер воно відображає правильні значки.
Максим

13

Kill TGitCache.exe працює для мене. .... Я ставлю це як відповідь, оскільки мені не вистачає очок репутації, щоб додати це як коментар. Але хотів допомогти далі повторити, що це робоче рішення.


1
Якщо це вірна відповідь, тоді немає шкоди, якщо поставити її як відповідь. Можливо, ви можете надати трохи більше деталей про те, як це вирішує проблему.
Кмейкснер

Це єдине, що мені вдалося, але я не знаю, чи безпечно просто вбити TGitCache.exe. Здається, я в безпеці, але, можливо, я просто збиваю банку по дорозі.
Лукас

Дубльоване рішення розчину Енді за 5 років до цього.
Талія

13

Існує обхідний шлях, який я спробував:

Перейменуйте каталог сховища, а потім змініть його назад, і все готово!

Як приклад: MyComplexProject можна змінити на MyComplexProject1, а потім повернути на MyComplexProject .


2
якщо це божевільно, і це працює, це не божевільно. спасибі за це!
xandermonkey

1
Це спрацювало після того, як не вдалося вбити процес кешування; один файл мене прослуховував місяцями.
Еріка Кейн

Це має бути прийнятим рішенням, оскільки це фактично змушує TortoiseGit очистити кеш накладеного значка. Вбивство всього процесу здається надмірним.
Extragorey

10

Окрім згадуваного @Andy, ви можете змусити накладання працювати швидше, обмеживши папки, які він повинен контролювати.

Клацніть правою кнопкою миші-> TortoiseGit -> Налаштування -> Накладання піктограм

Тут введіть шляхи включення та виключення. Зазвичай я прямо вказую на мої репо / робочі копії:

введіть тут опис зображення


8

Будь ласка, перевірте свій шлях, щоб перевірити, чи відповідає він на випадок.

Some/Dir/SomeFile.ext

є однаковим для вікон, як

some/DIR/someFILE.EXT

Але для Git вони знаходяться в різних місцях. Це виправляється шляхом повернення назад зверху за допомогою відповідного кожуха.


1
У моєму випадку файл під назвою "resource.h" був перейменований Visual Studio на "Resource.h".
kol

ding ding ding. це те, що відбувалося. Дякую.
DrFloyd5

8

У мене була та сама проблема в Windows.

Вбивство TGitCache справді спрацювало пару секунд, але червоний значок знову з’явився.

Виявилося, що файл було перейменовано (перша буква була змінена з великої на малу) регіонально, але в Git вона не була змінена. Windows не враховує регістр, але Git - це! Отже, накладення піктограм більше не збігалося. Я дізнався це, видаливши конкретний файл і вибравши "повернути" з контекстного меню Turtoise Git. У списку справді з'явилися два файли, один із першої літери великим, інший - повною малими.

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


4
Ця тема розпочалась 15 листопада '11. Сьогодні 27 березня 2018 року. Ну, більше 6 років і немає рішення? Давай Черепаха!
JohnCz

1
у моєму випадку графічний інтерфейс gitlab показав два файли з різними регістрами. Видаліть один із них у графічному інтерфейсі, витягнувши зміни та повернувши зміни, вирішили проблему.
алеха

1
Це була моя проблема. Я змінив випадок розширення зображень у своєму проекті, я повернувся до старих імен.
TazAstroSpacial

1
Чудово, дякую за ваш підказку! Коли це божевілля з урахуванням регістру зупиниться;)
джаз

5

Коли піктограми не оновлюються, ви можете швидко вбити кеш накладеного значка, використовуючи таку команду "Виконати":

taskkill /f /im tgitcache.exe

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


2

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

Якщо ви не настільки впевнені в собі (або просто не хочете ризикувати, як найкраще), перейменуйте свою папку репо lcoally і перевірте репо знову, тоді ви можете потягнути різницю, щоб побачити, чи немає чогось дивного / змінився між двома папками репо.


2

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

У будь-якому випадку, ось що я роблю, щоб вирішити це:

git gc --prune=all --quiet

Він обрізає сховище Git, перепаковуючи всі ці окремі об'єктні файли, зменшуючи кількість файлів у .git з десятків тисяч до менше 20, і, ймовірно, покращуючи загальну продуктивність операцій Git.

Іноді Git робить полегшену версію цього самостійно після коміту, але я рідко коли-небудь бачив, щоб це траплялося за роки щоденного використання. Тому я просто роблю це сам. Це також чудова дія, яку слід розглянути перед тим, як зробити резервну копію системи (див. Нижче).

Щоб полегшити це, я створив пакетний файл git-gcall.cmdу доступному шляху, який викликає команду, показану вище. Мені доводиться запускати його практично після кожного окремого коміту, а через 2-3 секунди піктограми оновлюються самі. Ніяких вбивств. Просто пробуджуючи TortoiseGit трохи важче, щоб насправді спостерігати за сховищем та оновлювати його статус.


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

gc-all-git.ps1:

Write-Host "Packing Git repositories where necessary..."

function Git-Gc($path)
{
    cd $path
    Get-ChildItem . -Recurse -Hidden .git | Foreach-Object {
        cd $_.FullName
        if ((Get-ChildItem objects -File -Recurse).Count -gt 50)
        {
            cd ../
            Write-Host $(Get-Location).Path
            git gc --prune=all --quiet
        }
    }
}

Git-Gc C:\Source
Git-Gc C:\xampp\htdocs

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

gc-all-git.cmd:

@echo off
cd /d "%~dp0"
%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy unrestricted -File gc-all-git.ps1
exit /b %errorlevel%

1

Я думаю, ця проблема трапилася у мене через програми, що конкурують за накладання піктограм обмежень Windows (я вважаю, що це дозволяє максимум 15).

Ось що мені довелося зробити, щоб вирішити цю проблему:

  1. Відкрийте regeditта перейдіть доComputer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers клавіші.
  2. Переставте підклавіси так, щоб клавіші Tortoise * знаходились у верхній частині, додавши префікси з пробілами.
  3. Перезапустіть Провідник Windows за допомогою диспетчера завдань.

Дивіться також: TortoiseGit не відображає накладання значків


1

Рішення для нас вирішило те, що ми перенесли свої репозиторії Git на відображений мережевий диск, змінивши таким чином букву диска.

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

Отже, щоб вирішити це питання, ви повинні:

  • Клацніть правою кнопкою миші папку репо
  • Виберіть "TortoiseGit"
  • Виберіть "Налаштування"
  • Виберіть "Накладання піктограм"
  • Поставте галочку "Мережні диски"

Робота виконана.


0

Це може допомогти ... Моя буква диска була B: і значки накладання не оновлювались. Я змінив його на C :, (я використовував M :), і він почав працювати. Схоже, TGIT не рухається нижче C:


Існує окреме налаштування під накладами піктограм, яке включає "Диски A: і B:" - ці букви завжди традиційно використовувались для дисководів дискети.
PeterJ

0

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

PS Я переконався, що контрольна сума CRC64 для всього каталогу була однаковою до і після цієї операції.


0

Не впевнений, чи це актуально.

Схоже, у TortoiseGit виникли проблеми з кешем у випадках із файлами / папками.

У моєму випадку, оскільки регістр папки був неправильним із очікуваним колись, накладання піктограм не відображалося

Різниця регістрів Z в назві папки zeta

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