Considerando che Git non riconosce i collegamenti simbolici che puntano al di fuori del repository, c'è qualche problema nell'utilizzo dei collegamenti fisici?Git e hard link
Potrebbe Git romperli? Potete indicarmi informazioni dettagliate?
L'oggetto "albero", che rappresenta le directory in Git, memorizza le autorizzazioni del nome file e del sottoinsieme. Non memorizza il numero di inode (o un altro tipo di ID file). Pertanto i collegamenti rigidi non possono essere rappresentati in git, almeno non senza strumenti di terze parti come metastore o git-cache-meta (e non sono sicuro che sia possibile anche con quegli strumenti).
Git prova a non toccare i file che non ha bisogno di aggiornare, ma devi prendere in considerazione che git non tenta di preservare i collegamenti fisici, quindi possono essere interrotti da git.
circa link simbolici che puntano repository di fuori: git non ha problemi con loro e dovrebbe conservare contenuti dei link simbolici ... ma l'utilità di tali collegamenti è dubbia a me, come se tali link simbolici sarebbero rotte o non dipende dal layout del filesystem fuori repository git e non sotto controllo di git.
I collegamenti simbolici ai percorsi al di fuori del repository possono essere utili. Li ho usati nelle applicazioni web per puntare a database o file multimediali non tracciati dal repository. In questo modo, il file di configurazione dell'app Web può puntare a un percorso statico, ma la posizione effettiva di quel percorso può variare tra lo sviluppo locale e gli ambienti server. – mipadi
@mipadi: BTW. Il gitweb moderno ha un caso speciale per la visualizzazione di collegamenti simbolici dopo la normalizzazione al di fuori del repository. –
Sì, i link simbolici al di fuori del repository vanno bene. Li ho usati per indicare una enorme directory di dati che non avevo bisogno (o volevo) di versionned. Generalmente utilizzo i collegamenti relativi. Quindi nel caso di maggio il repository e la directory dei dati dovevano sedersi uno accanto all'altro in qualche directory principale. Puoi fare trucchi incredibili con un symlink a ../foo. –
Da questo msysgit issue
punti di giunzione sono collegamenti non simbolici; pertanto, i collegamenti simbolici sono semplicemente non supportati in msysGit.
Inoltre, i collegamenti rigidi di non sono mai stati tracciati da Git.
Il problema era orientato a Windows (poiché si tratta di msysgit) e il dibattito sul potenziale supporto di symlink.
Ma il commento su hard link riguarda Git in generale.
Google 'git preservare i collegamenti fisici' e mostra che git non sa come preservare la struttura dei collegamenti rigidi AFAIK, forse di progettazione.
progetti Web di mine usano hard link come segue:
www/products/index.php
www/products/dell_latitude_id577/index.php #(hard linked to above)
www/products/dell_inspiron_id323/index.php #(hard linked again to above)
[email protected]:www/products$ ls -l index.php
-rwxr-xr-x 3 me me 1958 Aug 22 22:10 index.php*
Se avessi voluto fare i cambiamenti a index.php lo cambio in un posto e gli hard link (pagine di dettaglio del prodotto) indicare le modifiche - eccetto git non mantiene questa relazione durante la clonazione e l'estrazione su altri computer.
[email protected]:www$ git pull
su un'altra macchina creerà un nuovo index.php per ciascun collegamento.
Dovresti implementare una sorta di routing nella tua webapp. L'hard linking è bizzarro. – Nowaker
Sì, almeno usare i collegamenti simbolici. :) –
Ok, ora si tratta di un ritardo di risposta = D
ho scoperto che, utilizzando i ganci, è possibile catturare l'evento git pull (quando c'è qualcosa per tirare ...) scrivendo il gestore di eventi script per .git/hooks/post-merge file.
In primo luogo, è necessario chmod +x esso.
Quindi, inserire i comandi ln al suo interno per ricreare collegamenti rigidi a ogni pull. Pulito eh!
Funziona, ho solo bisogno di quello per il mio progetto e ls -i mostra che i file sono stati collegati automaticamente dopo pull.
Il mio esempio di .git/hooks/post-merge:
#!/bin/sh
ln -f $GIT_DIR/../apresentacao/apresentacao.pdf $GIT_DIR/../capa/apresentacao.pdf
ln -f $GIT_DIR/../avaliacoesMono/avaliacao_monografias_2011_Nilo.pdf $GIT_DIR/../capa/avaliacoes.pdf
ln -f $GIT_DIR/../posters/poster_Nilo_sci.pdf $GIT_DIR/../capa/poster.pdf
ln -f $GIT_DIR/../monografia/monografia_Nilo.pdf $GIT_DIR/../capa/monografia_Nilo.pdf
IMPORTANTE: Come si può vedere, il percorso a qualsiasi file nel repository dovrebbe iniziare con $GIT_DIR, quindi aggiungere il percorso relativo parziale del file.
Importante: -f è necessario, poiché si sta ricreando il file di destinazione.
Così sembra che ogni volta che aggiungi un hardlink al repository, devi anche aggiungere manualmente una linea allo script di hook post-merge. Sarebbe bello se il tuo hook di pre-commit lo rendesse completamente automatico - rilevando link (e simbolici) duri nel tuo commit e scrivendo le righe appropriate nel tuo file post-merge. Git non avrebbe dovuto memorizzare le informazioni inode nel repository, ne conserverebbe dei bit nei ganci! Ma che casino se il file collegato è stato rintracciato in un altro repository git ... una modifica al file in un posto si propagherà facilmente all'altro repository? Il perpetuo si fonde con un loop push/pull circolare? – hobs
Approccio intelligente, ma è un peccato che Git non tenga traccia degli hard link, nemmeno potenzialmente li rappresenta come copie su file system che non supportano i collegamenti fisici. –
Cosa stai cercando di fare e perché? Un hard link non è diverso da un file normale. Se dovessi mai estrarre una nuova versione da un altro repository, sovrascriverebbe quella che avevi - qual è il punto di collegamento a qualcosa al di fuori del repository? –
Git riconoscerà i collegamenti simbolici che puntano a un percorso esterno al repository. – mipadi
No mipadi, l'unico modo è agitare i file nel repository e i collegamenti simbolici nella loro posizione "reale" –