package test;
public class Test {
public static int i = 1;
}
Zmieniamy jej nazwę na TestA. W historii widzimy elegancki rename
Zmieńmy nieco samą klasę:
package test;
public class TestA {
public static int i = 1;
public static TestA test1;
public static TestA test2;
public static TestA test3;
public static TestA test4;
public static TestA test5;
public static TestA test6;
public static TestA test7;
}
Znowu zmieniamy nazwę, tym razem w historii nie ma rename, za to wygląda to tak jakbyśmy usunęli plik i dodali inny:
Taki commit może bardzo negatywnie wpłynąć na poszukiwania kto coś zepsuł, bo przecież to wtedy najbardziej potrzebujemy historii (razem z ewentualnymi renamami). Pytanie co się stało? Ano niewiele osób wie (a może to tylko ja nie wiedziałem), że korzystając z Gita rename pliku i ewentualne zmiany na nim powinny być commitowane w 2 osobnych commitach. Wtedy w historii zawsze widoczne będą renamy. Dlaczego w taki razie zmiana nazwy z Test na TestA skomitowana była w jednym commicie i historia nadal jest ok? Git jest na tyle sprytny, że sprawdza jakie są procentowe zmiany względem rozmiaru pliku i jeśli ten procent jest poniżej (lub powyżej w zależności od tego co, przez co podzielimy) magicznej zmiennej -M to wykrywa taką operację jako rename. W przeciwnym razie traktuje rename jako 2 osobne pliki, jeden dodany, drugi usunięty. I to zostało zasymulowane w przypadku zmiany nazwy TestA na TestB.
Na szczęście w Javie zmiana nazwy klasy, w 90% przypadków, powoduje zmianę w 1 linijcie pliku, więc można śmiało commitować wszystko na raz, choć profesjonalista zrobi to w osobnych commitach, co nawet eclipse wspiera z automatu.
Ja się już kiedyś spotkałem z takim zachowaniem i również wpadłem na magiczny parametr -M.
OdpowiedzUsuńZastanawiam się jednak dalej, czy jest możliwość wymuszenia, aby Git potraktował drugą zmianę jako rename? Commit lub add nie mają flagi -M :/
Ja niestety nie znalazłem żadnej informacji o tym, że można tym sterować, ale to nie znaczy, że nie ma takiej opcji.
OdpowiedzUsuń