Git: nie można utworzyć dowiązania symbolicznego (nazwa pliku jest zbyt długa)

Question

Popchnąłem projekt z Linuksa do bitbucked, a następnie sklonowałem go w systemie Windows. Okazało się, że były dwa dowiązania symboliczne, które pojawiły się jako pliki tekstowe w oknach. Ponieważ wiedziałem, gdzie powinny wskazywać, zastąpiłem je kopiami ich plików docelowych, popełnione i pchnął.

Teraz repozytorium butbucket wygląda dobrze, gdy patrzę na niego z poziomu interfejsu internetowego. Jednak klon git na moim komputerze unixa daje mi dwie wiadomości, takie jak:

error: unable to create symlink ... (File name too long) 

oraz dwa pliki, które wcześniej były dowiązaniami symbolicznymi. Próbowałem klonować do/tmp/..., aby uzyskać krótsze nazwy plików, ale otrzymałem takie same wyniki. Sugeruje to, że coś poszło nie tak z repozytorium bitbucket. Próbowałem włączać i wyłączać core.symlinks.

Mogę żyć bez dowiązań symbolicznych, ale chciałbym mieć działające repozytorium. Czy ktokolwiek zna sposób (inny niż odtworzenie repozytorium)?

Answer 1

Jak tylko zmieniłeś zawartość pliku fałszywego-symlink-a, nie zmieniając również jego trybu z dowiązania symbolicznego do zwykłego i zatwierdziłeś wynik, zrobiłeś blob, którego nie można wyodrębnić w systemie operacyjnym z prawdziwymi dowiązaniami symbolicznymi, ponieważ masz obiekt, który ma być dowiązaniem symbolicznym, ale jego zawartość jest zbyt długa, aby mogła być nazwą ścieżki. Interfejs sieciowy nie robi ci żadnych korzyści, ukrywając ten problem.

Prawdopodobnie będziesz musiał wykonać kopię zapasową tego zatwierdzenia, naprawić i ponownie zatwierdzić wszystko po nim. Pomocne może być git rebase -i, ale może to nie być łatwe, szczególnie jeśli wprowadzono więcej zmian w plikach, gdy znajdowały się one w tym fałszywym stanie symlink-ale-nie-naprawdę-a-symlink.

Przypuśćmy, że złe jest abcdef123 popełnić, trzeba to zrobić:

git rebase -i 'abcdef123^' 

które będzie można umieścić w edytorze z listy zobowiązuje. abcdef123 powinien znajdować się w pierwszym wierszu. W tej linii zmień pick na edit. Jeśli jest więcej niż jedno złe zatwierdzenie, zmień je wszystkie na edit. Zapisz i zamknij edytor.

Teraz wrócisz do punktu, w którym popełniłeś zły plik. To jest Twoja szansa, aby zmienić historię, naprawiając wszystko, co kiedyś poszło nie tak. Sprawdzić commit z

git show 

i cofnąć złe część przywracając pierwotną symlink ścieżkę do pliku i git add ing go. Lub naprawdę możesz naprawdę usunąć link symboliczny z git rm, a następnie utworzyć nowy plik i git add, który. Jeśli wybierzesz pierwszą opcję, pamiętaj, że treść dowiązania symbolicznego jest po prostu ścieżką. To nie jest plik tekstowy - na końcu nie ma znaku nowej linii. Jeśli zmienisz go za pomocą edytora tekstu, który doda znak nowej linii, będziesz miał uszkodzone dowiązanie symboliczne (wskazując na plik z nowym znakiem w jego nazwie).

Po wykonaniu swój git add, włóż stałe popełnić w jego miejsce w historii:

git commit --amend 
git rebase --continue 

Jeśli zmieniono wiele z pick zobowiązuje do edit trzeba będzie powtórzyć tę procedurę dla każdego z nich. Ostateczny git rebase --continue przywróci cię do teraźniejszości.

Jeśli jesteś w przeszłości zatwierdzenia podczas rebase i odkrywasz, że całe zatwierdzenie jest złe (nie zrobił nic innego oprócz zamiany dowiązania symbolicznego do niezmodyfikowanej zawartości pliku, do którego wskazuje), wtedy możesz git rebase --skip zamiast zmieniając i kontynuując. Jeśli wiesz z wyprzedzeniem, że tak się stanie, możesz po prostu usunąć złe zatwierdzenie z listy git rebase -i zamiast zmienić jego pick na edit.

Jeśli masz wiele oddziałów, na które wpływ mają złe zatwierdzenia, konieczne będzie powtórzenie całej procedury dla każdego oddziału. Sprawdź oddział, uruchom git rebase -i do ukończenia (co oznacza, że ​​git rebase --continue mówi "Zakończono pomyślnie"), a następnie sprawdź kolejną gałąź i zrób to jeszcze raz.

W przyszłości, dzieląc pracę programistyczną między systemem Windows a rzeczywistym systemem operacyjnym, system Windows będzie działał z cygwin. Wewnątrz cygwin, dowiązania symboliczne są dowiązaniami symbolicznymi i nie można ich zepsuć tak jak robiłeś.

Answer 2

Oto rozwiązanie, które nie wymaga cofania i naprawiania zatwierdzeń. W końcu może nie być możliwe, jeśli repozytorium jest zdalne lub udostępnione. Używa core.symlinks = false. Mówiłeś, że próbowałeś tego, ale nie powiedziałeś kiedy. Musisz to zrobić przed kasą, którą domyślnie wykonuje normalny klon. Musisz sklonować opcję --no-checkout.

git clone --no-checkout the-repo tmp-clone-dir 
cd tmp-clone-dir 
git config core.symlinks false 
git checkout 
cp the-problem-file the-problem-file.bak # make a backup 
git rm the-problem-file 
git commit -m 'Removed problem file pretending to be a symlink' the-problem-file 
mv the-problem-file.bak the-problem-file # restore the backup; now it will be of type file 
git commit -m 'Added back the problem file - now with the correct type' the-problem-file 
git push origin master 
cd .. 
\rm -rf tmp-clone-dir # IMPORTANT 

Ten ostatni krok jest ważny, ponieważ nie chcesz robić więcej pracy w repozytorium z core.symlinks = false. Po prostu proszą o kłopoty.

Powyższe zakłada, że ​​plik ma być plikiem, a nie dowiązaniem symbolicznym. Jeśli miał to być dowiązanie symboliczne, zatrzymałbyś się po pierwszym zatwierdzeniu, usuń katalog-tmp-clone i wróć do normalnego czeku repo, aby utworzyć dowiązanie symboliczne i je zatwierdzić.

Zaletą tej metody jest to, że nie łamie się żadnych powiązanych klonów i gałęzi, ponieważ zachowuje historię. Wadą tego jest to, że złamane zatwierdzenie nadal istnieje i spowoduje problemy dla każdego, kto spróbuje użyć tego konkretnego złego zatwierdzenia.

Answer 3

miałem ten problem, to rozwiązać to dla mnie:

git config core.symlinks false 
git rm <problem-file> 
git commit <problem-file> 
git push 
git config core.symlinks true 

Answer 4

Jest również łatwiejszy sposób, jeśli używasz bitbucket. Od teraz bitbucket obsługuje usuwanie plików online, które możesz przejść do repo na bitbucket, znaleźć plik, który jest problematyczny, naciśnij przycisk w pobliżu przycisku "Edytuj" i "Usuń".

Spowoduje to usunięcie pliku z uszkodzonym dowiązaniem symbolicznym i ponownie pojawi się katalog roboczy. jeśli jest to możliwe, jest to znacznie szybsze niż ręczne ponowne zapisywanie i usuwanie.