git clone --depth 10 <repo>
のように、リビジョン数 [ git help revisions
] を指定する必要がある git コマンドがいくつかあります。
コミットとリビジョンの違いは何ですか ( svn ではなくgit で)?
または、リビジョン/コミットを数えようとするときに複数形でのみ表示されますか?
git clone --depth 10 <repo>
のように、リビジョン数 [ git help revisions
] を指定する必要がある git コマンドがいくつかあります。
コミットとリビジョンの違いは何ですか ( svn ではなくgit で)?
または、リビジョン/コミットを数えようとするときに複数形でのみ表示されますか?
git rev-parseの「 SPECIFYING REVISIONS」を参照してください。
リビジョン パラメータ
<rev>
は通常、コミット オブジェクトの名前を指定しますが、必ずしもそうである必要はありません。
拡張 SHA1 構文と呼ばれるものを使用し、さまざまな方法でオブジェクト名を綴ります。
したがって、「リビジョン」は、git 内のオブジェクト (通常はコミット)を参照するためのパラメーターとして使用できる ID を指します。
HEAD@{5 minutes ago}
5分前に存在したコミットを参照するリビジョンです。
gitrevision
言及:
[...] 一部の Git コマンド ( など)は、コミット以外のオブジェクト、たとえばblob (「ファイル」) やツリー(「ファイルのディレクトリ」) を示すリビジョン パラメーター
git show
も受け取ります。
たとえば、次の rev パラメータはコミットを参照しません。
<rev>:<path>, e.g. HEAD:README, :README, master:./README
接尾辞の
:
後にパスが続くと、コロンの前の部分によって名前が付けられたツリー風のオブジェクト内の指定されたパスにあるブロブまたはツリーの名前が付けられます。
Git の「コミット」は、通常、「コミットオブジェクト」を指定します (たとえば、次のように説明されgit commit-tree
ています)。
コミットは以下をカプセル化します。
- すべての親オブジェクト ID
- 著者名、電子メール、日付
- コミッター名と電子メール、およびコミット時間。
そう:
あなたの場合 ( git clone
)--depth <n>
は:
指定されたリビジョン数に切り捨てられた履歴を持つ浅いクローンを作成します。
n
これは、DAG 内のパスごとのリビジョンまで、その深さでアクセス可能なすべてのコミット用です。
結果はコミット以上のものになる可能性があるため、ここではリビジョンという用語をより適応させて、コミットだけが必要ではなく、最大のリビジョンで参照されるすべてのコミットがアクセス可能であるn
ことを強調します。n
n
ただし、この文脈では、リビジョンは明らかにコミットのみを参照します(以下に示すように)到達可能です(「 git clone --depth 1
(浅いクローン)は実際よりも便利ですか?」で述べたように)。
問題は「何から到達可能か」ですか?
以下を含むこのスレッドを参照しました。
IIRC
--depth=<n>
は、「深化<n>
」ではなく、「少なくとも<n>
更新されたヒントから持っていることを確認してください」。
シャロー クローン ハックは、過去にシャロー クローンを作成--depth
し、反対側が よりも多くのコミットを追加した後にでフェッチした場合、(内部的には一貫している可能性がありますが) まったく役に立たないセマンティクスを提供<n>
します。<n>
なしで実際にフェッチする必要はありません--depth
。
面白い。以前はこの区別に出くわしたことはありませんでしたが、ドキュメントと私自身の経験をざっと見てみると、git のコミットは、プロジェクトの歴史の特定の時点を指すオブジェクトです (それがどのようにそこに到達したかに関する情報と共に)。 . リビジョンは、コミットまたはコミットの範囲を参照するさまざまな方法について説明する、これのスーパーセットです。