Czy najlepiej będzie, gdy będę używać skryptu powłoki, który zastępuje dowiązania symboliczne kopiami, czy też jest inny sposób, aby powiedzieć Gitowi, by podążał za dowiązaniami symbolicznymi?

PS: Wiem, że nie jest to zbyt bezpieczne, ale chcę to zrobić tylko w kilku konkretnych przypadkach.

UWAGA: Ta rada jest obecnie nieaktualna zgodnie z komentarzem od wersji Git 1.6.1. Git zachowywał się w ten sposób i już tego nie robi.

Git domyślnie próbuje przechowywać dowiązania symboliczne zamiast je śledzić (dla zwięzłości i to jest to, czego ludzie chcą).

Jednak przypadkowo udało mi się go dodać, aby dodać pliki poza dowiązaniem symbolicznym, gdy dowiązanie symboliczne jest katalogiem.

To znaczy:

  /foo/
  /foo/baz
  /bar/foo --> /foo
  /bar/foo/baz

wykonując

 git add /bar/foo/baz

wydawało się, że działa, kiedy próbowałem. Zachowanie to było jednak przeze mnie niepożądane, więc nie mogę przekazać ci informacji poza tym.

Co zrobiłem, aby dodać pliki z dowiązania symbolicznego do Git (nie użyłem dowiązania symbolicznego, ale):

sudo mount --bind SOURCEDIRECTORY TARGETDIRECTORY

Wykonaj to polecenie w katalogu zarządzanym przez Git. TARGETDIRECTORYmusi zostać utworzony przed SOURCEDIRECTORYzamontowaniem w nim.

Działa dobrze w systemie Linux, ale nie w systemie OS X! Ta sztuczka pomogła mi również w Subversion. Używam go do dołączania plików z konta Dropbox, na którym projektant robi swoje rzeczy.

Dlaczego nie utworzyć dowiązań symbolicznych na odwrót? Oznacza to, że zamiast łączyć z repozytorium Git do katalogu aplikacji, wystarczy połączyć na odwrót.

Załóżmy na przykład, że konfiguruję zainstalowaną aplikację, ~/applicationktóra potrzebuje pliku konfiguracyjnego config.conf:

• Dodaję config.confdo mojego repozytorium Git, na przykład o ~/repos/application/config.conf.
• Następnie tworzę dowiązanie symboliczne ~/application, uruchamiając ln -s ~/repos/application/config.conf.

To podejście może nie zawsze działać, ale jak dotąd działało dobrze.

Zamiast tego użyj twardych linków. Różni się to od miękkiego (symbolicznego) łącza. Wszystkie programy, w tym również gitbędą traktować plik jako zwykły plik. Należy pamiętać, że zawartość może być modyfikowana poprzez zmianę albo źródła lub przeznaczenia.

Na macOS (wcześniej niż 10.13 High Sierra)

Jeśli masz już zainstalowane git i Xcode, zainstaluj hardlink . To mikroskopijne narzędzie do tworzenia twardych łączy .

Aby utworzyć twardy link, po prostu:

hln source destination

Aktualizacja systemu macOS High Sierra

Czy system plików Apple obsługuje twarde łącza do katalogu?

Twarde łącza do katalogów nie są obsługiwane przez system plików Apple. Wszystkie twarde łącza do katalogu są konwertowane na dowiązania symboliczne lub aliasy podczas konwersji z formatów woluminów HFS + na APFS w systemie macOS.

Z APFS FAQ na developer.apple.com

Śledź https://github.com/selkhateeb/hardlink/issues/31, aby znaleźć przyszłe alternatywy.

W systemie Linux i innych wersjach Uniksa

lnPolecenie może zrobić dowiązania twarde:

ln source destination

W systemie Windows (Vista, 7, 8,…)

Ktoś zasugerował, aby użyć mklink utworzyć połączenie w systemie Windows, ale nie próbowałem:

mklink /j "source" "destination"

Jest to haczyk poprzedzający zatwierdzenie, który zastępuje obiekty BLOB symboliczne w indeksie zawartością tych dowiązań symbolicznych.

Włóż to .git/hooks/pre-commiti zrób to:

#!/bin/sh
# (replace "find ." with "find ./<path>" below, to work with only specific paths)

# (these lines are really all one line, on multiple lines for clarity)
# ...find symlinks which do not dereference to directories...
find . -type l -exec test '!' -d {} ';' -print -exec sh -c \
# ...remove the symlink blob, and add the content diff, to the index/cache
    'git rm --cached "$1"; diff -au /dev/null "$1" | git apply --cached -p1 -' \
# ...and call out to "sh".
    "process_links_to_nondir" {} ';'

# the end

Notatki

Używamy w jak największym stopniu funkcjonalności zgodnej z POSIX; jednak diff -anie jest zgodny z POSIX, być może między innymi.

W tym kodzie mogą występować błędy / błędy, mimo że został on nieco przetestowany.

Włącz MacOS(mam Mojave / 10.14, gitwersja 2.7.1), użyj bindfs.

brew install bindfs

cd /path/to/git_controlled_dir

mkdir local_copy_dir

bindfs </full/path/to/source_dir> </full/path/to/local_copy_dir>

Wskazały na to inne komentarze, ale nie zostały jasno podane w innych odpowiedziach. Mam nadzieję, że zaoszczędzi to komuś trochę czasu.

Od dłuższego czasu dodawałem pliki poza dowiązaniami symbolicznymi. Kiedyś działało dobrze, bez żadnych specjalnych ustaleń. Ponieważ zaktualizowałem do wersji Git 1.6.1, to już nie działa.

Możesz być w stanie przełączyć się na Git 1.6.0, aby to zadziałało. Mam nadzieję, że przyszła wersja Gita będzie miała flagę git-addpozwalającą mu ponownie podążać za dowiązaniami symbolicznymi.

Zmęczyło mnie każde rozwiązanie, które jest przestarzałe lub wymaga rootowania, więc stworzyłem rozwiązanie oparte na LD_PRELOAD (tylko Linux).

Wchodzi w wewnętrzne elementy Gita, zastępując „czy to dowiązanie symboliczne?” funkcja, umożliwiająca traktowanie dowiązań symbolicznych jako ich zawartości. Domyślnie wszystkie linki do zewnętrznych repozytoriów są wstawiane; zobacz link, aby uzyskać szczegółowe informacje.

W przypadku Git 2.3.2+ (I kwartał 2015 r.) Istnieje jeszcze jeden przypadek, w którym Git nie będzie już podążał za dowiązaniem symbolicznym: patrz commit e0d201b przez Junio ​​C Hamano ( gitster) (główny opiekun Git)

apply: nie dotykaj pliku poza dowiązaniem symbolicznym

Ponieważ Git śledzi dowiązania symboliczne jako dowiązania symboliczne, ścieżka, która ma dowiązanie symboliczne w swojej wiodącej części (np. path/to/dir/fileGdzie path/to/dirjest dowiązanie symboliczne do innego miejsca, czy to wewnątrz czy na zewnątrz działającego drzewa), nigdy nie może pojawić się w poprawnej poprawce , chyba że ta sama poprawka najpierw usunie dowiązanie symboliczne, aby umożliwić utworzenie tam katalogu.

Wykryj i odrzuć taką łatkę.

Podobnie, gdy dane wejściowe tworzą dowiązanie symboliczne, path/to/dira następnie plik path/to/dir/file, musimy oflagować je jako błąd bez faktycznego tworzenia path/to/dirdowiązania symbolicznego w systemie plików.

Zamiast tego w przypadku każdej poprawki na wejściu, która pozostawia ścieżkę (tj. Brak usunięcia) w wyniku, sprawdzamy wszystkie wiodące ścieżki względem wynikowego drzewa, które utworzy łatka, sprawdzając wszystkie łaty na wejściu, a następnie cel poprawki aplikacja (indeks lub drzewo robocze).

W ten sposób:

• złapać błąd lub pomyłkę, aby jednocześnie dodać symboliczny link path/to/diri plik path/to/dir/file,
• jednocześnie zezwalając na prawidłową poprawkę, która usuwa symbolikę, link path/to/dira następnie dodaje plik path/to/dir/file.

Oznacza to, że w takim przypadku komunikat o błędzie nie będzie ogólny "%s: patch does not apply", ale bardziej szczegółowy:

affected file '%s' is beyond a symbolic link

Hmmm, mount --bindnie działa na Darwina.

Czy ktoś ma taką sztuczkę?

[edytowany]

OK, znalazłem odpowiedź na Mac OS X, aby utworzyć hardlink. Tyle że ten interfejs API nie jest lnudostępniany przez , więc musisz użyć własnego małego programu, aby to zrobić. Oto link do tego programu:

Tworzenie twardych linków do katalogów w Mac OS X.

Cieszyć się!

Korzystam z Git 1.5.4.3 i podąża za przekazanym dowiązaniem symbolicznym, jeśli ma ukośnik końcowy. Na przykład

# Adds the symlink itself
$ git add symlink

# Follows symlink and adds the denoted directory's contents
$ git add symlink/

Konwersja z dowiązań symbolicznych może być przydatna. Łącze w folderze Git zamiast dowiązania symbolicznego za pomocą skryptu .