web-dev-qa-db-ja.com

Gitでtree-ishはどういう意味ですか？

git archiveの使用方法について非常に混乱しています。

フォルダーFoo、Bar、およびBazを持つgitリポジトリがありますトップレベル。迅速なテスト展開のために、SVNのような方法でフォルダーFooをエクスポートする必要があります。

git-archiveを SVN-ishエクスポートのような方法で使用できることを学びました 。

しかし、ここにあります、次はうまくいきます：

git archive master | tar -x -C ~/destination

Foo、Bar、Bazフォルダーdestinationフォルダー。

ただし、以下はfatal not a valid object nameでエラーになります：

git archive master/foo | tar -x -C ~/destination

ドキュメント

git archiveプログラムの概要を見ると、パラメータとして<tree-ish> [path]を取ることができることがわかります（概要は関連する部分にまとめられています）。

git archive <tree-ish> [path...]

Ifmaster/foois nottree-ish、それから何ですか？

gitgit-archive
106
dkinzer

ショートアンサー（TL; DR）

「ツリーのような」とは、最終的に（サブ）ディレクトリツリーにつながる任意の識別子（ Gitリビジョンドキュメント で指定）を指す用語です（Gitはディレクトリを「ツリー」および「ツリーオブジェクト」）。

元のポスターの場合、fooは、指定したいディレクトリです。 Gitで（サブ）ディレクトリを指定する正しい方法は、この「ツリーっぽい」構文（ Gitリビジョンドキュメント のアイテム＃15）を使用することです。

<rev>:<path>、例： HEAD:README、:README、master:./README

接尾辞:の後にパスが続くと、コロンの前の部分で名前が付けられたツリーのようなオブジェクトの指定されたパスにあるblobまたはツリーに名前が付けられます。

つまり、言い換えると、master:fooはmaster/fooではなく、正しい構文です。

その他の「ツリーっぽい」（プラスコミットっぽい）

以下は、コミットのような識別子とツリーのような識別子の完全なリストです（ Gitリビジョンドキュメント 、 指摘してくれたLopSaeに感謝します ）：

----------------------------------------------------------------------
|    Commit-ish/Tree-ish    |                Examples
----------------------------------------------------------------------
|  1. <sha1>                | dae86e1950b1277e545cee180551750029cfe735
|  2. <describeOutput>      | v1.7.4.2-679-g3bee7fb
|  3. <refname>             | master, heads/master, refs/heads/master
|  4. <refname>@{<date>}    | master@{yesterday}, HEAD@{5 minutes ago}
|  5. <refname>@{<n>}       | master@{1}
|  6. @{<n>}                | @{1}
|  7. @{-<n>}               | @{-1}
|  8. <refname>@{upstream}  | master@{upstream}, @{u}
|  9. <rev>^                | HEAD^, v1.5.1^0
| 10. <rev>~<n>             | master~3
| 11. <rev>^{<type>}        | v0.99.8^{commit}
| 12. <rev>^{}              | v0.99.8^{}
| 13. <rev>^{/<text>}       | HEAD^{/fix nasty bug}
| 14. :/<text>              | :/fix nasty bug
----------------------------------------------------------------------
|       Tree-ish only       |                Examples
----------------------------------------------------------------------
| 15. <rev>:<path>          | HEAD:README, :README, master:./README
----------------------------------------------------------------------
|         Tree-ish?         |                Examples
----------------------------------------------------------------------
| 16. :<n>:<path>           | :0:README, :README
----------------------------------------------------------------------

識別子＃1-14はすべてコミットにつながるため、すべて「コミットに似ています」が、コミットはディレクトリツリーも指すため、最終的にはすべて（サブ）ディレクトリツリーオブジェクトにつながり、したがって「ツリー」としても使用できます。 -Hは"。

＃15は（サブ）ディレクトリを参照するときにツリーのように使用できますが、特定のファイルを識別するためにも使用できます。ファイルを参照するとき、それがまだ「ツリーっぽい」と考えられているのか、それとも「blob-ish」のように振る舞うのかはわかりません（Gitはファイルを「blobs」と呼びます）。

長い答え

最下位レベルでは、Gitは4つの基本オブジェクトを使用してソースコードを追跡します。

  1. コミットを指す注釈付きタグ。
  2. コミット。プロジェクトのルートディレクトリツリーを指します。
  3. ツリー。ディレクトリとサブディレクトリです。
  4. ファイルであるブロブ。

Linus Torvaldsは content-addressable ファイルシステムのようにGitを設計したため、これらの各オブジェクトには独自のsha1ハッシュIDがあります。つまり、コンテンツに基づいてファイルを取得できます（sha1 IDはファイルコンテンツから生成されます）。 Pro Gitブックでは、 このサンプル図 ：

Figure 9-3 from Pro Git book

多くのGitコマンドは、コミットおよび（サブ）ディレクトリツリーの特別な識別子を受け入れることができます。

  • 「Commit-ish」は、最終的にコミットオブジェクトにつながる識別子です。例えば、

    tag -> commit

  • 「ツリーっぽい」とは、最終的にツリー（ディレクトリ）オブジェクトにつながる識別子です。

    tag -> commit -> project-root-directory

コミットオブジェクトは常にディレクトリツリーオブジェクト（プロジェクトのルートディレクトリ）を指しているため、定義により、「コミットに似た」識別子はすべて「ツリーに似た」定義にもなります。言い換えれば、コミットオブジェクトにつながる任意の識別子を使用して、（サブ）ディレクトリツリーオブジェクトに導くこともできます。

ただし、ディレクトリツリーオブジェクトはGitのバージョン管理システムでコミットを指すことはないため、（サブ）ディレクトリツリーを指すすべての識別子を使用してコミットを指すことはできません。言い換えると、「コミットのような」識別子のセットは「ツリーのような」識別子のセットの厳密なサブセットです。

ドキュメント で説明されているように（ Treborが見つけてくれてありがとう ）：

<tree>

ツリーオブジェクト名を示します。

<commit>

コミットオブジェクト名を示します。

<tree-ish>

ツリー、コミット、またはタグのオブジェクト名を示します。 <tree-ish>引数を取るコマンドは、最終的に<tree>オブジェクトを操作したいが、<commit>を指す<tag>および<tree>オブジェクトを自動的に逆参照します。

<commit-ish>

コミットまたはタグのオブジェクト名を示します。 <commit-ish>引数を取るコマンドは、最終的に<commit>オブジェクトを操作したいが、<tag>を指す<commit>オブジェクトを自動的に逆参照します。

がcommit-ishとして使用できないツリー状の識別子のセット

  1. <rev>:<path>。これは、を直接に導き、オブジェクトをコミットしません。たとえば、HEAD:subdirectory。

  2. ディレクトリツリーオブジェクトのSha1識別子。

148
user456814

ツリーっぽいは、次のいずれかの特定のツリーに名前を付ける方法です。

  • 次のような参照：
    • HEAD
    • タグ
    • 支店名
    • Origin/somebranchのようなリモートのブランチ名
  • ハッシュ
  • 短いハッシュ

さらに、上記のいずれにも^、~を追加できます。参照では、いくつかの追加機能に@{}表記を使用することもできます。

  • HEAD^またはHEAD^1は、HEADの最初の親に解決されます。
  • HEAD^2は2番目の親に解決されます
  • HEAD^3は3番目の親などに解決されますが、これはよりまれで、 タコ戦略とマージ の結果です。
  • HEAD~またはHEAD~1は、headの最初の親に解決されます
  • HEAD~2は、HEADの最初の親の最初の親に解決されます。これはHEAD^^と同じです
  • HEAD@{0}は現在のHEADに解決されます
  • HEAD@{1}は前のヘッドに解決されます。これは参照ログを使用するため、参照でのみ使用できます。 HEADのすべてのコミット、マージ、チェックアウトの場合、HEAD=の値が変更され、ログに追加されます。git reflog HEADは参照ログを表示します。 HEADのすべての動きと、適切に@{1}などが解決するものを見ることができます。

上記のほとんどは、リポジトリで意味がある限り、さらに組み合わせることができます。たとえば、HEAD@{2}~3、somebranch^2~4、c00e66e~4^2、anotherbranch~^~^~^などです。

したがって、上記のいずれか、およびその組み合わせは、ドキュメンテーションでツリーっぽいものとして意味されます。これは、ほとんどのgitコマンドで使用されるツリー（またはリビジョン）を示すための単なる方法です。

Gitブックのリビジョン選択 で詳細を確認してください。

47
LopSae

あなたはおそらく欲しい

git archive master foo | tar -x -C ~/destination

表現 master/fooは意味がありません：masterはブランチ名で、fooはディレクトリ名です。

編集：（壊れたリンクを削除しました。コメントを参照してください。）

11
Sven Marnach

<tree-ish>および<commit-ish>の定義については、 git（1） manページを参照してください。用語を検索する必要があります。一般的に<tree-ish>はgitツリーオブジェクトへの参照を意味しますが、ツリーを参照するオブジェクトのタイプ（コミットやブランチなど）を渡すと、gitは参照されたツリーを自動的に使用します。

5
Trebor Rude

From Git Glossary tree-ishは、「ツリーオブジェクト、またはツリーオブジェクトを再帰的に逆参照できるオブジェクト」です。 commit、HEADおよびtagはツリーのようなオブジェクトの例です。

0
user2494386

私はソース管理とgitの初心者です。これは私が知っていることです。ツリーは、リポジトリ内のファイルの構造です。ファイルシステムのディレクトリに似ています。参照- どのgitツールがこのツリービューを生成しましたか？

木っぽいというのは、木のようなものです。ツリーの一部またはコミットを参照します。コミットのSHA-1ハッシュの完全または一部、HEADポインター、ブランチ参照、タグ参照。これらのメソッドのいずれかを使用する別のメソッド。祖先またはコミットの親とともに、祖先の例： enter image description here

0
stack1