Gdy plik zostanie już raz zaindeksowany, można przestać śledzić jego stan usuwając wszystkie informacje z repozytorium dotyczące tego pliku, wykonując komendę git rm --cached nazwa_pliku i dodając odpowiedni wpis do pliku .gitignore. Nie jest to jednak to, co chcielibyśmy osiągnąć w przypadku plików, bez których aplikacja przestaje działać – bo co w przypadku, gdy zrobimy git clone? Nasza nowa instancja nie będzie zawierała tego pliku i grozi nam fatal error. Samo dodanie do .gitignore również nie rozwiązuje problemu, bo Git tak czy siak podpowiada zmiany w pliku i z łatwością można nieświadomie zatwierdzić zmiany w tym pliku używając git commit -a.

Z pomocą przychodzi mechanizm Gita, któremu możemy zasugerować, że zmiany w zaindeksowanym pliku nas nie obchodzą. Git zachowuje się wtedy tak, jakby plik miał dokładnie tą samą zawartość co wtedy, gdy był commitowany. Realizowane jest to za pomocą komendy update-index, a konkretniej git update-index --assume-unchanged <nazwa_pliku>. Oczywiście raz „zignorowany” plik możemy zacząć śledzić na nowo, wydając komendę git update-index --no-assume-unchanged <nazwa_pliku>, co daje deweloperom pole manewru i pozwala na odsianie zmian, których aktualnie nie chcą zatwierdzać (przebijanie się przez listę zmienionych plików przed każdym commitem bywa męczące) i ewentualne powracanie do nich, gdy już przyszła ich kolej.

Łatwo się jednak zagubić w tym co zostało „zignorowane”, a co nie, więc żeby sobie ułatwić jeszcze bardziej, możemy zdeklarować globalny alias git config --global alias.ignored '!git ls-files -v | grep "^[[:lower:]]"', dzięki któremu wywołując komendę git ignored uzyskamy listę plików, które w danym repozytorium posiadają bit assume-unchanged (takie pliki komenda git ls-files -v listuje używając małych liter dla flagi pliku, poczytaj).

Przydatne np. dla konfiguracji połączeń z bazą danych, definicji stałych określających ścieżki do plików i tego typu rzeczy, które są potrzebne, które mogą się różnić w zależności od środowiska, w którym uruchamiana jest aplikacja, a których zmian nie ma potrzeby commitować bo nijak nie wpływają na historię wersji.