22

次のシェル コードは、シンボリック参照のチェーンを正しく作成します。

git symbolic-ref "first" "refs/heads/master"
git symbolic-ref "second" "first"
git symbolic-ref "nested/third" "second"
git symbolic-ref "refs/heads/fourth" "nested/third"

また、次のシェル コードは、最後に作成されたシンボリック参照を master の先端に正しく解決します。

git show-ref "refs/heads/fourth"

これらの使用例は、公式ドキュメント ( git-symbolic-ref doc、git-show-ref doc ) には記載されていません。

ただし、以下は機能しません

 git check-ref-format --print "first"

だから、私の質問は次のとおりです。

  • refs/headsディレクトリ内にシンボリック参照を保存してもよろしいですか?
  • シンボリック参照を連鎖させても大丈夫ですか?
  • を渡すと check-ref-format が失敗"first"するため、 と同じレベルでシンボリック参照を作成することは推奨されないということ"HEAD"ですか? それとも、このコマンドはシンボリック リンクを処理するためのものではないのでしょうか?

私の意図は、何がサポートされているか、そして私が何かを回避したり、バグの恩恵を受けたりしていないことを明確に理解することです.

4

3 に答える 3

17

最終的に、この質問を git 開発メーリング リストに投稿しました。

リード git メンテナー (+8700 コミ​​ット) であるJunio C Hamanoは、次の回答を提供してくれました。

現在、有効な symref の種類は 2 つだけです。

  • .git/HEAD、refs/heads/ 階層の下のどこかを指しています。

  • .git/refs/remotes/{some remote name}/HEAD、refs/remotes/{the same remote name}/ 階層の下のどこかを指しています。

コードは、再帰的な symref、上記の 2 種類以外の symref、他の場所を指す symref を解決するように準備されている場合がありますが、それらはすべて、メカニズムがサポートすることを意図した設計範囲外です。コードが（クラッシュせずに）それらに対して行うことは設計ではなく、単に未定義の動作です。

これは、1.8.0 でリモート追跡階層を再編成することにしたとしても、あまり変わらないでしょう。前者はまったく変更されず、後者は代わりに refs/remotes/{the same remote name}/heads 階層を指し始めます。

tg が symref メカニズムを悪用して .git/HEAD をおかしな場所に向けたのを漠然と思い出しました。まだそうしている可能性があり、その場合は、上記のリストを拡張してその使用法をカバーする必要があります。

于 2011-02-15T06:49:42.177 に答える
3

通常、symrefs は以下に存在しますrefs/— 少なくとも、これは git スイートが行うことです (たとえば、git filter-tree を使用すると、 が得られますrefs/original/...)。refs/一部のツールは、プレフィックスを持たない参照を無視することを選択する場合があります。

$ git symbolic-ref refs/first refs/heads/master
$ git check-ref-format --print refs/first
refs/first
于 2011-02-13T20:37:36.110 に答える
2

シンボリック リンクをより透過的に使用でき、同様にプッシュできることが望ましいでしょう。これらは、新しいワークフローの強力なツールになる可能性があります。現在、シンボリックリンクを作成してからプッシュすると、サーバーは対応する参照のリンクではなくハッシュを持ちます。

于 2014-05-10T03:38:17.207 に答える