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

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ć).

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

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

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

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.

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 .

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

Napotkałem ten sam problem. I to uratuje mi życie: https://gist.github.com/jtdp/5443498

git diff -p -R --no-color \
| grep -E "^(diff|(old|new) mode)" --color=never  \
| git apply`

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.

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

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>

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.