この場合、ファイルシステムの境界を超えない場合は、ハードリンクを使用できます。知らなかった場合、ハードリンクはシンボリックリンクと非常に似ていますが、プロセスの観点から見ると、ファイルは通常のファイルです。これには、それを正しく処理し、シンボリックリンクの代わりにコンテンツを含む一般的なファイルとして保持するgitが含まれます。

しかし、gitはこれらのリンクを追跡しないので、何らかの理由でファイルがリポジトリによって削除されて再生成されると、ハードリンクが失われるため、gitを使用するときに注意する必要があります。

明確に言うと、Pretzoのメインストレージインスタンスでgitサポートポイントファイルが保存されているディレクトリのバージョンにハードリンクを作成することを意味します。 Pretzoはそれを通常のファイルとして扱い、gitはそれを普通のファイルとして扱います。ハードリンクファイルはシンボリックリンクされているため、この方法で展開することは問題になりません。

シンボリックリンクと同様に、これはあるバージョンの変更が別のバージョンに変更されることを意味します。技術的には、ストレージ（複数の関連ファイルノードを含む）の同じデータであるためです。ハードリンクは明示的に表示されないことが多いため、多くのツールを使用するシンボリックリンクよりも気づくのは難しいです。 （これがさまざまなGUIファイルブラウザにどのように適用されるかはわかりません。通常は通常のファイルにすぎないと思います。）しかし、ls -l表示されたリンクの数（2番目の列）などstatに基づいてこれを見つけることができます。ハードリンクされていない一般ファイルのリンク数は1です（ディレクトリはいいえ通常ファイルなのでリンク数が異なります) 残念ながら、シンボリックリンクとは異なり、他のノードを簡単に見つける方法はありません。、存在を示すリンクの数。したがって、このタスクを無作為に開始するのではなく、この場合のように体系的に実行して、他のノードの理由と場所を知ることができます。

警告する

これは、この方法で複数のシステムに展開する場合（この時点であなたの投稿が明確ではない）、問題が発生する可能性があることを意味します。プレスト楽章これらのファイルを直接変更するのは簡単です。これはファイルが待機中の更新に合格しますが、pullその更新はPretzoによって行われたローカルの変更と競合し、この時点ではマージが悪い可能性があるため、何をすべきかを判断する必要があります（ハードリンクを削除できることに注意してください）。他のすべてのコピーは削除されません）。

しかし、これがPretzoが読み取りだけで変更しない設定ファイルであることがわかっている場合（gitがシステム全体でファイルを追跡するというアイデアに多少暗示されています）、それは問題ありません。また、このリポジトリを特定のシステムのバックアップとして使用してもかまいません。上記の状況は発生しません。

唯一の他の問題は、ファイルシステムの境界を超えてハードリンクを使用できないことです。つまり、デフォルトのgitサポートリポジトリがPretzo独自のリポジトリとは別にマウントされたファイルシステムにある場合、このアプローチは使用できません。