http://www.stardust.webpages.pl/ltg/ Po polsku rozdział o Git

Śledzenie zmian nazw katalogów

Git nie śledzi zmian nazw katalogów. Jeśli edytujesz istniejący plik, zmiany będą scalone kiedy scalisz razem ze zmianą nazwy.

Ale jeśli dodajesz nowy plik i nazwa katalogu została zmieniona, plik będzie zachowany w katalogu o starej nazwie.

[1] [2]

Do rozwinięcia

Koncepcja gita, że śledzi pliki i ich zawartość, a nie katalogi. Jakie to ma konsekwencje?

Mamy taki przykład: jeden programista zmienia nazwę katalogu w swojej gałęzi, a inny dodaje plik do oryginalnego katalogu w swojej gałęzi. Co się stanie przy scalaniu? - Bazaar zmienia nazwę katalogu i umieszcza nowy plik w katalogu o _zmienionej_ nazwie. - Git zmienia nazwę katalogu z plikami, ale zostawia także stary katalog i dodaje do niego nowy plik.

Zachowanie Bazaara jest na pewno lepsze dla programów pisanych w C. Jakkolwiek nie jest zawsze lepsze.

Na przykład w Javie nie możesz zmienić nazwy pliku bez zmieniania jego zawartości. Tak więc przenoszenie pliku do katalogu innego od tego, do którego umieścił autor, prawie na pewno zepsuje etap kompilacji.

Rezultat jest taki, że obydwa zachowania wydają się właściwe lub błędne, w zależności od sytuacji. Nic nie jest idealne. Na bardzo abstrakcyjnym poziomie zmiany nazw plików nie są operacjami wyższego priorytetu. To jest szczególnie widoczne w języku takim jak Java.

Przemieszczanie się zawartości jest operacją wyższego priorytetu. Sytuacje jak przemieszczanie się funkcji, itp. Pytanie jest, jak można obsługiwać to i czy aktualna strategia ma możliwość ulepszenia. Można argumentować, że kiedy zaczniesz jawnie śledzić zmiany nazw plików, pozbawiasz się możliwości obsługi bardziej ogólnych przypadków.

Jedno jest pewne, 100% idealne rozwiązanie jest niemożliwe. Musi być nastawione na docelowy język programowania i środowisko kompilacji.

http://jan-krueger.net/development/git-cheat-sheet-extended-edition