Jak usunąć pliki z napisem „stary tryb 100755 nowy tryb 100644” z nieustawionych zmian w Git?

723

Z jakiegoś powodu, kiedy początkowo ściągałem z repozytorium mojego projektu git, dostałem mnóstwo plików w mojej kopii roboczej, które nie zawierają widocznych zmian, ale wciąż pojawiają się w mojej unstaged changesokolicy.

Używam Git Gui na Windows XP i kiedy idę do pliku, aby zobaczyć, co się zmieniło. Widzę tylko:

old mode 100755  
new mode 100644  

Czy ktokolwiek wie, co to znaczy?

Jak mogę usunąć te pliki z mojej listy nieustawionych zmian? (Bardzo denerwujące jest to, że muszę przejrzeć setki plików, aby wybrać pliki, które ostatnio edytowałem i chcę zatwierdzić).

concept47
źródło

Odpowiedzi:

1284

Dla mnie wygląda to na tryby uprawnień do plików unix ( 755= rwxr-xr-x, 644= rw-r--r--) - stary tryb zawierał flagę + x (wykonywalną), nowy tryb nie.

Odpowiedzi na ten problem msysgit sugerują ustawienie wartości core.filemode na false, aby pozbyć się problemu:

git config core.filemode false
Bursztyn
źródło
132
+1. Oznacza to, że git myśli, że może poprawnie ustawić bit wykonywalny na pobranych plikach, ale gdy próbuje to zrobić, nie działa (a przynajmniej nie w sposób, który potrafi odczytać). Kiedy następnie odczytuje status tych plików, wygląda na to, że bit wykonywalny został celowo rozbrojony. Ustawienie wartości core.filemode na false powoduje, że git ignoruje wszelkie zmiany bitów wykonywalnych w systemie plików, aby nie widział tego jako zmiany. Jeśli musisz wprowadzić zmianę bitu wykonywalnego, oznacza to, że musisz to zrobić ręcznie git update-index --chmod=(+|-)x <path>.
CB Bailey,
7
Jeśli, podobnie jak ja, zmiany trybu są ważne, możesz ustawić tryb core.filemode na false, zatwierdzić rzeczywiste zmiany kodu, a następnie ustawić tryb core.filemode na true, a git zachowa zmiany pliku.
Michael T. Smith,
8
Mam ten sam problem, ale wynikało to z używania tego samego repozytorium git przez linię SSH git cmd i przez rozszerzenia Git na zmapowanym dysku w systemie Windows! . . Rozwiązanie było takie samo, dodane do „config” [core] filemode = false
Ian Vaughan
2
To był ratownik, dziękuję! Zdarzyło mi się to w OSX po udostępnieniu sklonowanego repozytorium w folderze publicznym i zmianie uprawnień do plików.
Thiago Ganzarolli,
8
@robsch Za pomocą git config --global ...można ustawić opcję w globalnym pliku konfiguracyjnym.
Amber
98

Ustawienie wartości core.filemodefalse działa, ale upewnij się, że ustawienia ~/.gitconfignie są nadpisywane przez osoby w nim ustawione .git/config.

NovelX
źródło
3
Byłem tam, zrobiłem to. Niestety znalazłem twój komentarz dopiero po samodzielnym rozwiązaniu problemu. Nadal +1!
David Schmitt
1
Jeśli inni użytkownicy klonują ten projekt w systemie Windows, najlepiej może po prostu zastosować zmianę do ~/.gitconfigpliku!
Ian Vaughan,
Jeśli chcesz sprawdzić w Windows Powershell. git config --list --show-origin | sls filemodelub w systemie Linux git config --list --show-origin | grep filemode. To pokaże, gdzie należy wprowadzić zmiany.
Frank Fu
Udało wam się!! Dobra robota.
Kim
27

Ten problem napotkałem kilka razy podczas kopiowania repozytorium git z działającymi plikami ze starego dysku twardego. Problem wynika z faktu, że właściciel i uprawnienia zmieniły się ze starego dysku / komputera na nowy. Krótko mówiąc, uruchom następujące polecenia, aby wyprostować sytuację ( dzięki tej odpowiedzi administratora ):

sudo chmod -R -x . # remove the executable bit from all files

Poprzednie polecenie faktycznie rozwiązuje różnice zgłaszane przez git diff, ale odwoła twoją zdolność do wyświetlania katalogów, więc ls ./nie powiedzie się ls: .: Permission denied. Aby to naprawić:

sudo chmod -R +X . # add the executable bit only for directories

Zła wiadomość jest taka, że ​​jeśli masz jakieś pliki, które chcesz zachować, takie jak .shskrypty, musisz je przywrócić. Możesz to zrobić za pomocą następującego polecenia dla każdego pliku:

chmod +x ./build.sh # where build.sh is the file you want to make executable again
Scott Willeke
źródło
2
Dzięki, bardzo mi pomogłeś! Należy również sprawdzić, czy git config core.filemodejest ustawiona na true, w przeciwnym razie zmiany uprawnień nie zostaną wykryte. Musiałem także odświeżyć indeks git po każdej zmianie, aby go pobrać.
pat-s
To rozwiązanie jest najbezpieczniejsze, jeśli martwisz się o zależne od niego zależności.
Jin
9

Zwykle dzieje się to, gdy repo jest klonowane między komputerami z systemem Windows i Linux / Unix.

Po prostu powiedz gitowi, aby zignorował zmianę trybu pliku, oto kilka sposobów:

  1. Konfiguracja TYLKO dla bieżącego repo:

    git config core.filemode false
    
  2. Konfiguracja globalna:

    git config --global core.filemode false
    
  3. Dodaj ~ / .gitconfig:

    [core]
         filemode = false
    

Po prostu wybierz jeden z nich.

K. Symbol
źródło
Globalna konfiguracja nie działa, ponieważ (tak sądzę) git tworzy repozytorium z tą opcją ustawioną na true (utworzyłem repo w systemie Linux)
Herrgott,
4

Wygląda na to, że zmieniłeś niektóre uprawnienia do katalogu. Wykonałem następujące kroki, aby go przywrócić.

$  git diff > backup-diff.txt                ### in case you have some other code changes 

$  git checkout .
SuperNova
źródło
3

Możesz spróbować git reset --hard HEAD, aby zresetować repo do oczekiwanego stanu domyślnego.

Doppelganger
źródło
8
Jeśli git nie był w stanie poprawnie ustawić / wykonać bitu wykonywalnego po ściągnięciu, po resecie nie będzie lepiej.
CB Bailey,
2
Przeniosłem niektóre projekty na dysk USB (fat32) i wróciłem z powrotem na moją maszynę ubuntu (ext4) i skończyłem z wieloma zmienionymi plikami, no cóż, atrybutami. git reset --hard HEADdziałało dla mnie idealnie. dzięki
cirovladimir
7
-1. OP stwierdza „po prostu wybrać pliki, które ostatnio edytowałem i chcę zatwierdzić”. Spowodowałoby to również usunięcie tych zmian.
whitfin
9
-1 Sugerowanie tego polecenia w git jest podobne do powiedzenia „możesz po prostu rm -rf ./, jestem pewien, że nie będzie to miało niezamierzonych konsekwencji”.
Kzqai
1
Nie, to nie pomaga i to jest problem. Resetujesz i czyścisz, a status git pokazuje zmiany trybu. Jest to poważny problem z Windows Git i myślę, że należy go naprawić, a nie tylko obejść, ignorując tryb plików.
vezenkov
1

Dzieje się tak, gdy wyciągasz i wszystkie pliki były wykonywalne w zdalnym repozytorium. Ponowne uruchomienie ich spowoduje, że wszystko wróci do normy.

chmod +x <yourfile> //For one file
chmod +x folder/* // For files in a folder

Może być konieczne wykonanie:

chmod -x <file> // Removes execute bit

zamiast tego, dla plików, które nie zostały ustawione jako pliki wykonywalne i zostały zmienione z powodu powyższej operacji. Jest lepszy sposób, aby to zrobić, ale jest to bardzo szybka i brudna poprawka.

IskandarG
źródło
1

Możesz użyć następującego polecenia, aby ponownie zmienić tryb pliku. git add --chmod=+x -- filename Następnie przekaż do oddziału.

Wae
źródło
0

Miałem tylko jeden kłopotliwy plik ze zmienionymi uprawnieniami. Aby przywrócić go indywidualnie, po prostu usunąłem go ręcznie za pomocą, rm <file>a następnie zrobiłem kasę, aby pobrać nową kopię.

Na szczęście jeszcze go nie wystawiłem.

Gdybym miał, mógłbym biec git reset -- <file>przed bieganiemgit checkout -- <file>

kEnobus
źródło
0

Właśnie natknąłem się na ten problem, gdy różnicowałem gałąź z mistrzem. Git zwrócił jeden błąd „trybu”, gdy spodziewałem się, że moja gałąź będzie identyczna z master. Naprawiłem to, usuwając plik, a następnie ponownie scalając wzorzec.

Najpierw uruchomiłem diff:

git checkout my-branch
git diff master

To zwróciło:

diff --git a/bin/script.sh b/bin/script.sh
old mode 100755
new mode 100644

Następnie wykonałem następujące czynności, aby naprawić:

rm bin/script.sh
git merge -X theirs master

Po tym git diffnie zwrócił żadnych różnic między gałęzią my i master.

Collin Krawll
źródło