SOに関する最近の質問に照らして、新しく作成されたブランチのポインターが指定されたコミットを指すgit cloneようなオプションがないのはなぜだろうかHEAD。上記の質問では、OPは、ユーザーが複製する必要がある特定のコミットに関する指示を提供しようとしています。
この質問は、;を使用して特定のバージョンにクローンを作成する方法に関するものではないことに注意してくださいreset。しかし、なぜそこにないのですか？
これまでの2つの答え（私がこれを書いた時点で、今ではもっとあります）は彼らの言うことは正しいですが、「なぜ」の質問には実際には答えていません。もちろん、「なぜ」の質問に答えるのは本当に難しいです。ただし、Gitのさまざまな部分の作成者を除きます（それでも、2人の頻繁なGit寄稿者が2つの異なる答えを出した場合はどうなりますか？）。
それでも、Gitの「哲学」をそのまま考えると、一般に、さまざまな転送プロトコルは参照に名前を付けることで機能します。それらがSHA-1を提供する場合、それはその参照のSHA-1です。すでにリポジトリへの直接（例えば、コマンドライン）のアクセス権を持っていない人のために、どれも1コマンドに建てられたのは、1つのIDでコミットを参照することができません。私は見つけることができる最も近いものな理由のために、この-、それは実際に良い理由である2は、このビットを-isドキュメント：git upload-archive
セキュリティ
履歴から削除されたがまだプルーニングされていない可能性のあるオブジェクトのプライバシーを保護するために、git-upload-archiveは、リポジトリの参照から到達できないコミットおよびツリーのアーカイブの提供を回避します。ただし、オブジェクトの到達可能性の計算には計算コストがかかるため、git-upload-archiveは、より厳密でありながらチェックしやすい一連のルールを実装します...
しかし、それは続けて言います：
configオプション
uploadArchive.allowUnreachableがtrueの場合、これらのルールは無視され、クライアントは任意のsha1式を使用できます。これは、到達不能なオブジェクトのプライバシーを気にしない場合、またはオブジェクトデータベースが非スマートhttp経由でアクセスできるようにすでに公開されている場合に役立ちます。
これはgit clone、最初に到達可能なすべてのオブジェクトを取得するため、特に興味深いものです。その後、ローカルクローンはSHA-1 IDによるコミットを簡単にチェックアウトできます（必要に応じて、そのIDを指すローカルブランチ名を作成するか、クローンをそのままにしておきます）。 「デタッチヘッド」モード）。
これらの2つの横流を考えると、現時点での「理由」に対する本当の答えは、「誰もそれを追加するほど気にしない」ということだと思います。:-)プライバシー引数が有効ですが、理由はありませんgit clone、それ以外のいくつかのブランチをチェックアウトするように指示することができます同じように、クローニングした後、IDによってコミットをチェックアウトすることができませんでしたmaster3とはgit clone -b ...。許可することの唯一の欠点は、Gitが（クローン作成プロセスが始まる前に）受信されるかどうかを事前にチェックできないことです。それはすることができ、それらが転送されているのでそう、フロントまで（その分岐ヒントや他のSHA-1値と一緒に）、参照名をチェックし素早く終了し、コピーを作成しません。-b sha1sha1git clone -b nonexistentbranch ssh://...
fatal: Remote branch nonexistentbranch not found in upstream origin
fatal: The remote end hung up unexpectedly
-bIDが許可されている場合は、クローン全体を取得します。「ああ、すみません、そのIDをチェックアウトできません。代わりに、マスターに任せます」などと言う必要があります。（これは、バストされたサブモジュールで現在発生していることです。）
1一方でgit upload-archive 、今、この「プライバシー」のルールを施行し、これは（それはバージョン1.7.8.1で導入されました）必ずしもそうではありませんでした。また、Git自体と一緒に配布されるサーバーを含む多くの（ほとんど？）git-webサーバーでは、任意のIDで表示できます。これがおそらく、「参照名のみ」コードが追加allowUnreachableされてからupload-archive数年後に追加された理由です（ただし、1.7.8以降および2.0.0より前のGitのリリースではルールを緩める方法がないことに注意してください）。したがって、「セキュリティ」の考え方は有効ですが、それが実施されなかった期間（1.7.8.1より前）がありました。
図2は、 Gitのリポジトリのうち、表向きはプライベートデータ「リーク」に数多くの方法があります。新しいファイルDocumentation / transfer-data-leaksがGit 2.11.1に表示されようとしていますが、Git 2.11.0では、プッシュされたが受け入れられなかったオブジェクトをすぐに削除するための内部機能が追加されています（特にcommit 722ff7f87を参照）。このようなオブジェクトは最終的にガベージコレクションされますが、その間、オブジェクトは公開されたままになります。
3実際には、デフォルトでgit cloneは、リモートのHEAD参照に対応すると思われるブランチのローカルチェックアウトが行われます。masterとにかく、通常はそれです。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加