Jak Git obsługuje linki symboliczne?

Jeśli mam plik lub katalog, który jest dowiązaniem symbolicznym, i przesyłam go do repozytorium Git, co się z nim stanie?

Zakładam, że pozostawia go jako łącze symboliczne, dopóki plik nie zostanie usunięty, a następnie, jeśli wyciągniesz plik ze starej wersji, po prostu utworzy normalny plik.

Co robi, gdy usuwam plik, do którego się odwołuje? Czy to tylko zatwierdza wiszący link?

Git po prostu przechowuje zawartość łącza (tj. Ścieżkę obiektu systemu plików, do którego się łączy) w „obiekcie blob”, tak jak w przypadku zwykłego pliku. Następnie przechowuje nazwę, tryb i typ (w tym fakt, że jest to dowiązanie symboliczne) w obiekcie drzewa reprezentującym jego zawierający katalog.

Podczas pobierania drzewa zawierającego łącze przywraca on obiekt jako dowiązanie symboliczne niezależnie od tego, czy istnieje docelowy system plików.

Usunięcie pliku, do którego odwołuje się dowiązanie symboliczne, nie wpływa w żaden sposób na dowiązanie symboliczne kontrolowane przez Git. Będziesz miał wiszące odniesienie. Od użytkownika zależy usunięcie lub zmiana linku, aby w razie potrzeby wskazał coś ważnego.

Możesz dowiedzieć się, co Git robi z plikiem, widząc, co robi po dodaniu go do indeksu. Indeks jest jak zatwierdzenie wstępne. Po zatwierdzeniu indeksu można użyć git checkoutdo przeniesienia wszystkiego, co było w indeksie z powrotem do katalogu roboczego. Co więc robi Git, gdy dodasz dowiązanie symboliczne do indeksu?

Aby się dowiedzieć, najpierw utwórz dowiązanie symboliczne:

$ ln -s /path/referenced/by/symlink symlink

Git jeszcze nie wie o tym pliku. git ls-filespozwala kontrolować swoje (indeks -sdrukuje statwyjście -Jak):

$ git ls-files -s ./symlink
[nothing]

Teraz dodaj zawartość dowiązania symbolicznego do składnicy obiektów Git, dodając go do indeksu. Po dodaniu pliku do indeksu Git przechowuje jego zawartość w magazynie obiektów Git.

$ git add ./symlink

Co więc zostało dodane?

$ git ls-files -s ./symlink
120000 1596f9db1b9610f238b78dd168ae33faa2dec15c 0       symlink

Hash jest odniesieniem do spakowanego obiektu, który został utworzony w magazynie obiektów Git. Możesz zbadać ten obiekt, jeśli zajrzysz .git/objects/15/96f9db1b9610f238b78dd168ae33faa2dec15cdo katalogu głównego repozytorium. To jest plik, który Git przechowuje w repozytorium, który możesz później sprawdzić. Jeśli przejrzysz ten plik, zobaczysz, że jest on bardzo mały. Nie przechowuje zawartości połączonego pliku.

(Uwaga 120000to tryb wymieniony w ls-filesdanych wyjściowych. Byłby podobny 100644do zwykłego pliku.)

Ale co Git robi z tym obiektem, gdy wypisujesz go z repozytorium i do swojego systemu plików? To zależy od core.symlinkskonfiguracji. Od man git-config:

core.symlinks

Jeśli false, dowiązania symboliczne są sprawdzane jako małe zwykłe pliki zawierające tekst łącza.

Tak więc, z dowiązaniem symbolicznym w repozytorium, przy kasie otrzymujesz albo plik tekstowy z odniesieniem do pełnej ścieżki systemu plików, albo odpowiednie dowiązanie symboliczne, w zależności od wartości core.symlinkskonfiguracji.

Tak czy inaczej dane, do których odwołuje się dowiązanie symboliczne, nie są przechowywane w repozytorium.

Uwaga redaktora: ten post może zawierać nieaktualne informacje. Zobacz komentarze i to pytanie dotyczące zmian w Git od 1.6.1.

Symlinkowane katalogi:

Ważne jest, aby pamiętać, co dzieje się, gdy istnieje katalog będący miękkim łączem. Każde pobranie Git wraz z aktualizacją usuwa link i czyni go normalnym katalogiem. Tego nauczyłem się na własnej skórze. Niektóre spostrzeżenia tu i tutaj.

Przykład

Przed

 ls -l
 lrwxrwxrwx 1 admin adm   29 Sep 30 15:28 src/somedir -> /mnt/somedir

git add/commit/push

It remains the same

Po git pullAND znaleziono kilka aktualizacji

 drwxrwsr-x 2 admin adm 4096 Oct  2 05:54 src/somedir