Git에서 나무의 의미는 무엇입니까?

Git에서 나무의 의미는 무엇입니까?

---

사용 방법에 대해 매우 혼란 스럽습니다 git archive.

최상위 폴더에 Foo , Bar 및 Baz 폴더가있는 git 저장소가 있습니다. 빠른 테스트 배포를 위해 Foo 폴더를 SVN 형식으로 내 보내야합니다.

내가 사용할 수있는 것을 알게 git-archive에서 방법의 SVN 틱 수출 정렬 .

그러나 여기에 문제가 있습니다 . 다음은 잘 작동합니다.

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

대상 폴더 에 Foo , Bar , Baz 폴더가 생성됩니다 .

그러나, 다음은 밖으로 오류가 발생하지 로 fatal not a valid object name:

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

설명서

git archive프로그램 의 개요 <tree-ish> [path]로 보면 매개 변수로 사용할 수 있음을 알 수 있습니다 (시놉시스는 관련 부분으로 요약).

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

master/foo 이 아닌 경우 tree-ish무엇입니까?

---

짧은 답변 (TL; DR)

"Tree-ish"는 궁극적으로 (하위) 디렉토리 트리 (Git 디렉토리를 "트리"및 "트리 오브젝트"라고 함)로 이어지는 모든 식별자 ( Git 개정판 문서에 지정된대로 )를 나타내는 용어입니다.

원래 포스터의 경우 그가 지정하려는 foo 디렉토리 입니다. Git에서 (하위) 디렉토리를 지정하는 올바른 방법은이 "tree-ish"구문을 사용하는 것입니다 ( Git 개정판 문서의 항목 # 15 ).

<rev>:<path>예를 들면 HEAD:README, :README,master:./README

접미사 :다음에 경로가 오는 경우 콜론 앞 부분에 의해 명명 된 tree-ish 객체의 지정된 경로에서 BLOB 또는 트리 이름이 지정됩니다.

즉, master:foo올바른 구문이 아니라 master/foo입니다.

다른 "Tree-ish"(Plus Commit-ish)

커밋-쉬 및 트리- 쉬쉬 식별자의 전체 목록은 다음과 같습니다 ( 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는 모두 커밋을 유발하기 때문에 모두 "커밋 된 (commit-ish)"이지만, 커밋은 디렉토리 트리를 가리 키기 때문에 궁극적으로 (하위) 디렉토리 트리 객체로 연결되므로 "트리"로도 사용될 수 있습니다. -ish ".

# 15는 (하위) 디렉토리를 가리킬 때 나무처럼 사용될 수 있지만 특정 파일을 식별하는 데에도 사용될 수 있습니다. 파일을 참조 할 때 여전히 "트리 -ish"로 간주되는지 또는 "blob-ish"처럼 작동하는지 확실하지 않습니다 (Git은 파일을 "blobs"라고 함).

긴 대답

Git은 가장 낮은 수준에서 다음 네 가지 기본 개체를 사용하여 소스 코드를 추적합니다.

1. 커밋을 가리키는 주석이 달린 태그.
2. 커밋. 프로젝트의 루트 디렉토리 트리를 가리 킵니다.
3. 디렉토리 및 하위 디렉토리 인 트리
4. Blob은 파일입니다.

Each of these objects has its own sha1 hash ID, since Linus Torvalds designed Git like an content- addressable filesystem, i.e. files can be retrieved based on their content (sha1 IDs are generated from file content). The Pro Git book gives this example diagram:

Many Git commands can accept special identifiers for commits and (sub)directory trees:

• "Commit-ish" are identifiers that ultimately lead to a commit object. For example,

  tag -> commit

• "Tree-ish" are identifiers that ultimately lead to tree (i.e. directory) objects.

  tag -> commit -> project-root-directory

Because commit objects always point to a directory tree object (the root directory of your project), any identifier that is "commit-ish" is, by definition, also "tree-ish". In other words, any identifier that leads to a commit object can also be used to lead to a (sub)directory tree object.

But since directory tree objects never point to commits in Git's versioning system, not every identifier that points to a (sub)directory tree can also be used to point to a commit. In other words, the set of "commit-ish" identifiers is a strict subset of the set of "tree-ish" identifiers.

As explained in the documentation (thanks to Trebor for helping me find it):

<tree>

Indicates a tree object name.

<commit>

Indicates a commit object name.

<tree-ish>

Indicates a tree, commit or tag object name. A command that takes a <tree-ish> argument ultimately wants to operate on a <tree> object but automatically dereferences <commit> and <tag> objects that point at a <tree>.

<commit-ish>

Indicates a commit or tag object name. A command that takes a <commit-ish> argument ultimately wants to operate on a <commit> object but automatically dereferences <tag> objects that point at a <commit>.

The set of tree-ish identifiers that cannot be used as commit-ish are

1. <rev>:<path>, which leads directly to directory trees, not commit objects. For example, HEAD:subdirectory.

2. Sha1 identifiers of directory tree objects.

---

A tree-ish is a way of naming a specific tree which can be one of the following:

• References like:
  • HEAD
  • Tags
  • Branch names
  • Branch names with remotes, like origin/somebranch
• Hash
• Short hashes

On top of that, any of the above can be appended with ^, ~. References can also use the @{} notation for some additional features:

• HEAD^ or HEAD^1 will be resolved to the first parent of HEAD.
• HEAD^2 will resolve to the second parent
• HEAD^3 will resolve to the third parent and so on, which is more rare and product of merges with the octopus strategy.
• HEAD~ or HEAD~1 will resolve to the first parent of head
• HEAD~2 will resolve to the first parent of the first parent of HEAD. This would be the same as HEAD^^
• HEAD@{0} will resolve to the current HEAD
• HEAD@{1} will resolve to the previous head. This can only be used by references since it makes use of the reference log. In the case of HEAD every commit, merge, checkout will change the value of HEAD and thus add it to the log. git reflog HEAD will display the reference log where you can see all the movements of HEAD and properly what @{1} and so on will resolve to.

Most of the above can be further combined as long as it makes sense in your repository, for example: HEAD@{2}~3, somebranch^2~4, c00e66e~4^2, anotherbranch~^~^~^.

So any of the described above, and its combinations, is what is meant in the documentation as a tree-ish, which is just a way to say what tree (or revision) is the one that should be used for most of git commands.

More info in Revision Selection in the Git book.

---

You probably want

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

The expression master/foo does not make sense: master is a branch name and foo is a directory name, as I presume.

Edit: (Removed broken link. See comments.)

---

For definitions of <tree-ish> and <commit-ish> see the git(1) man page. You'll have to search for the terms. In general <tree-ish> means a reference to a git tree object, but if you pass a type of object that references a tree (such as a commit or branch), git will automatically use the referenced tree.

---

I am a newbie to source control and git. This is what I know. A tree is the structure of files in a repository. Its similar to a directory in a file system.See - Which git tool generated this tree view?

Tree-ish means like a tree. It references a part or commit of a tree. You can reference a commit using any one of these: full or part of the SHA-1 hash of a commit, HEAD pointer, branch reference, tag reference. Another method uses any of the mentioned methods along with ancestors or parents of a commit. Ancestors example:

---

From Git Glossary tree-ish is "A tree object or an object that can be recursively dereferenced to a tree object." commit, HEAD and tag are examples of tree-ish objects.

참고URL : https://stackoverflow.com/questions/4044368/what-does-tree-ish-mean-in-git