Wenn man bedenkt, dass Git keine symbolischen Links erkennt, die nach außerhalb des Repositories zeigen, gibt es ein Problem mit harten Verbindungen?Git und harte Verbindungen
Konnte Git sie brechen? Können Sie mich bitte auf detaillierte Informationen hinweisen?
Das Baumobjekt, das Verzeichnisse in Git darstellt, speichert den Dateinamen und (Teilsatz von) Berechtigungen. Es speichert keine Inode-Nummer (oder eine andere Art von Datei-ID). Daher feste Verbindungenkann nicht in Git dargestellt werden, zumindest nicht ohne Third-Party-Tools wie metastore oder git-cache-meta (und ich bin mir nicht sicher, ob es sogar mit diesen Tools möglich ist).
Git versucht, Dateien nicht zu berühren, die es nicht aktualisieren muss, aber Sie müssen berücksichtigen, dass Git nicht versucht, Hardlinks zu erhalten, so dass sie von Git gebrochen werden können.
über symbolische Links außerhalb Repository zeigen: git keine Probleme mit ihnen und soll Inhalt von symbolischen Links bewahren ... aber Nützlichkeit solcher Links ist zweifelhaft zu mir, als ob diese Symlinks gebrochen werden würde oder nicht hängt von der Dateisystem-Layout außerhalb Git-Repository, und nicht unter Kontrolle von Git.
Symlinks zu Pfaden außerhalb des Repos können nützlich sein. Ich habe sie in Webapps verwendet, um auf Datenbank- oder Mediendateien zu verweisen, die nicht vom Repo erfasst wurden. Auf diese Weise kann die Konfigurationsdatei der Web-App auf einen statischen Pfad verweisen, der tatsächliche Pfad dieses Pfads kann jedoch zwischen lokalen Entwicklungs- und Serverumgebungen variieren. – mipadi
@mipadi: BTW. Modernes gitweb hat einen speziellen Fall für das Anzeigen von Symlinks, die nach der Normalisierung außerhalb des Repositories führen. –
Ja, Symlinks außerhalb des Repos sind in Ordnung. Ich habe sie benutzt, um auf ein riesiges Datenverzeichnis zu zeigen, das ich nicht benötigt (oder wollen). Generell verwende ich relative Links. In einigen Fällen mussten das Repo und das Datenverzeichnis in einem übergeordneten Verzeichnis nebeneinander liegen. Sie können erstaunliche Tricks mit einem symbolischen Link zu ../foo machen. –
Aus diesen msysgit issue
Junction Punkten sind keine symbolischen Links; Daher werden symbolische Links einfach in msysGit nicht unterstützt.
Auch harte Links wurden nie von Git verfolgt.
Das Problem war Windows-orientiert (da es über msysgit) und diskutieren über die mögliche Unterstützung von Symlink.
Aber der Kommentar über harte Link betrifft Git im Allgemeinen.
Google 'Git erhalten harte Links' und es zeigt, dass Git nicht wissen, wie man die harte Link-Struktur AFAIK erhalten kann, vielleicht durch Design.
Webprojekte von mir verwenden harte Links wie folgt:
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*
Wenn ich wollte Änderungen an index.php ich es an einem Ort und die Hard-Links (Produktdetailseiten) auf die Änderungen hinweisen ändern - außer Git behält diese Beziehung beim Klonen und Ziehen auf anderen Computern nicht.
[email protected]:www$ git pull
auf einer anderen Maschine wird eine neue index.php für jede feste Verbindung erstellen.
Sie sollten eine Art Routing in Ihrer Webanwendung implementieren. Hard-Linking ist bizarr. – Nowaker
Ja, zumindest symlinks verwenden. :) –
Ok, jetzt ist dies eine späte Antwort = D
fand ich heraus, dass mit Haken, können Sie das git pull Ereignis erfassen (wenn es etwas zu ziehen ...) Schreiben Sie das Skript Ereignishandler .git/hooks/post-merge Datei.
Zuerst müssen Sie chmod +x es.
Dann setzen Sie die ln Befehle darin, um harte Verbindungen bei jedem Ziehen neu zu erstellen. Ordentlich, huh!
Es funktioniert, ich brauchte nur, dass für mein Projekt und ls -i zeigt, dass Dateien automatisch nach pull verknüpft wurden.
Mein Beispiel .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
WICHTIG: Wie Sie sehen können, sollte der Pfad zu jeder Datei in Ihrem Repository mit $GIT_DIR beginnen, dann die teilweise den relativen Pfad zur Datei.
Auch wichtig: -f ist notwendig, weil Sie die Zieldatei neu erstellen.
So sieht es aus wie jedes Mal, wenn Sie einen Hardlink zu Ihrem Repo hinzufügen, müssen Sie auch manuell eine Zeile zu Ihrem Post-Merge-Hook-Skript hinzufügen. Wäre schön, wenn Ihr Pre-Commit-Hook dies vollautomatisch macht - das Erkennen von harten (und symbolischen) Links in Ihrem Commit und das Schreiben der entsprechenden Zeilen in Ihre Post-Merge-Datei. Git müsste keine Inode-Informationen im Repo speichern, es würde Teile davon in den Hooks speichern! Aber was für ein Durcheinander, wenn die verknüpfte Datei in einem anderen Git Repo verfolgt wurde ... würde eine Bearbeitung der Datei an einem Ort reibungslos zum anderen Repo übertragen? Perpetual fusioniert mit einer kreisförmigen Push/Pull-Schleife? – hobs
Cleverer Ansatz, aber es ist bedauerlich, dass Git keine festen Links verfolgt und sie sogar als Kopien auf Dateisystemen darstellt, die keine festen Links unterstützen. –
Was versuchen Sie und warum? Eine feste Verbindung unterscheidet sich nicht von einer normalen Datei. Wenn Sie jemals eine neue Version aus einem anderen Repository abrufen würden, würde dies die vorhandene Version überschreiben - was ist der Zweck der Verknüpfung mit etwas außerhalb des Repos? –
Git erkennt Symlinks, die auf einen Pfad außerhalb des Repositorys zeigen. – mipadi
Kein Mipadi, der einzige Weg ist das Winken der Dateien im Repo und der symbolischen Links an ihrem "richtigen" Ort. –