Что означает древовидное значение в Git?

Я очень смущен тем, как использовать git archive.

У меня есть репозиторий git с папкой Foo, Bar и Baz на верхнем уровне. Мне нужно экспортировать папку Foo в стиле SVN-ish для быстрого развертывания теста.

Я узнал, что я мог бы использовать git-archive в виде SVN-ish.

Но вот что, Следующее работает отлично:

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 , то что?

Ответ 1

Короткий ответ (TL; DR)

"Tree-ish" - это термин, который ссылается на любой идентификатор (как указано в Git ревизия документации), что в конечном итоге приводит к (под) каталогу tree (Git относится к каталогам как "деревья" и "древовидные объекты" ).

В исходном случае плаката foo - это каталог, который он хочет указывать. Правильный способ указать (под) каталог в Git - это использовать синтаксис "tree-ish" (элемент № 15 из документация по версиям Git):

<rev>:<path>, например. HEAD:README, :README, master:./README

Суффикс :, за которым следует путь, называет пучок или дерево по заданному пути в древовидный объект, названный частью до двоеточия.

Иными словами, master:foo - это правильный синтаксис, а не master/foo.

Другое "Tree-ish" (плюс Commit-ish)

Здесь приведен полный список идентификаторов commit-ish и tree-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>}    | [email protected]{yesterday}, [email protected]{5 minutes ago}
|  5. <refname>@{<n>}       | [email protected]{1}
|  6. @{<n>}                | @{1}
|  7. @{-<n>}               | @{-1}
|  8. <refname>@{upstream}  | [email protected]{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" , потому что все они приводят к фиксации, но потому что коммиты также указывают на деревья каталогов, все они в конечном итоге приводят к (sub), и поэтому их также можно использовать как "tree-ish" .

# 15 также может использоваться как древовидный, когда он ссылается на (под) каталог, но он также может использоваться для идентификации определенных файлов. Когда это относится к файлам, я не конечно, если он все еще считается "древовидным" или если он больше похож на "blob-ish" (Git относится к файлам как "blobs" ).

Длительный ответ

На своих младших уровнях Git отслеживает исходный код, используя четыре основных объекты:

  • Аннотированные теги, которые указывают на фиксацию.
  • Задает, указывая на корневое дерево каталогов вашего проекта.
  • Деревья, которые являются каталогами и подкаталогами.
  • Blobs, которые являются файлами.

Каждый из этих объектов имеет свой собственный идентификатор хэша sha1, поскольку разработанный Линус Торвальдс Git как файловая система content-addressable, то есть файлы могут быть восстановлены на основе их содержимого (идентификаторы sha1 генерируются из содержимого файла). Pro Git книга дает эту диаграмму примера:

Figure 9-3 from Pro Git book

Многие команды Git могут принимать специальные идентификаторы для commits и (sub) directory деревья:

  • "Commit-ish" - это идентификаторы, которые в конечном итоге приводят к объекту фиксации. Например,

    tag -> commit

  • "Tree-ish" - это идентификаторы, которые в конечном итоге приводят к созданию объектов дерева (например, каталога).

    tag -> commit -> project-root-directory

Поскольку объекты фиксации всегда указывают на объект дерева каталогов (корень каталог вашего проекта), любой идентификатор, который является "commit-ish" , является определение, также "tree-ish" . Другими словами, любой идентификатор, который приводит к объект commit также может использоваться для создания объекта дерева подкаталогов.

Но поскольку объекты дерева каталогов никогда не указывают на фиксацию в версии Git система, а не каждый идентификатор, указывающий на дерево подкаталогов (sub), также может быть используется для указания на фиксацию. Другими словами, набор идентификаторов "commit-ish" является строгим подмножеством множества "древовидных" идентификаторов.

Как объяснено в документации (благодаря Trebor за помощь я найду его):

<tree>

Указывает имя древовидного объекта.

<commit>

Указывает имя объекта фиксации.

<tree-ish>

Указывает имя объекта дерева, фиксации или тега. Команда, которая принимает <tree-ish>аргумент в конечном итоге хочет работать с объектом <tree>, но автоматически dereferences <commit> и <tag> объекты, которые указывают на a <tree>.

<commit-ish>

Указывает имя объекта фиксации или тега. Команда, которая принимает <commit-ish>аргумент в конечном итоге хочет работать с объектом <commit>, но автоматически dereferences <tag> объекты, которые указывают на <commit>.

Набор идентификаторов дерева, которые не может использоваться как commit-ish,

  • <rev>:<path>, который приводит непосредственно к деревьям каталогов, а не commit объекты. Например, HEAD:subdirectory.

  • Идентификаторы Sha1 объектов дерева каталогов.

Ответ 2

Дерево-иш - это способ присвоения имени конкретному дереву, которое может быть одним из следующих:

  • Ссылки:
    • ГОЛОВКА
    • Теги
    • Имена веток
    • Имена веток с пультом, например origin/somebranch
  • Hash
  • Короткие хэши

Кроме того, любой из вышеперечисленных может быть добавлен с помощью ^, ~. Ссылки могут также использовать нотацию @{} для некоторых дополнительных функций:

  • HEAD^ или HEAD^1 будет разрешен для первого родителя HEAD.
  • HEAD^2 разрешит второй родительский
  • HEAD^3 будет разрешаться третьим родителям и т.д., что является более редким, а продукт сливается с стратегией осьминогов.
  • HEAD~ или HEAD~1 будет разрешаться для первого родителя головы
  • HEAD~2 будет разрешен для первого родителя первого родителя HEAD. Это будет то же самое, что и HEAD^^
  • [email protected]{0} разрешит текущую HEAD
  • [email protected]{1} будет разрешено предыдущему голосу. Это можно использовать только для ссылок, поскольку оно использует справочный журнал. В случае HEAD каждое commit, merge, checkout изменяет значение HEAD и, таким образом, добавляет его в журнал. git reflog HEAD отобразит справочный журнал, где вы сможете увидеть все движения HEAD и правильно, что будет @{1} и т.д.

Большинство из приведенных выше можно объединить, если это имеет смысл в вашем репозитории, например: [email protected]{2}~3, somebranch^2~4, c00e66e~4^2, anotherbranch~^~^~^.

Таким образом, любое из описанных выше и его комбинаций - это то, что подразумевается в документации как древовидный, что является просто способом сказать, какое дерево (или ревизия) является тем, которое должно использоваться для большей части git.

Дополнительная информация в Выбор редакции в книге git.

Ответ 3

Вероятно, вы хотите

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

Выражение master/foo не имеет смысла: master - это имя ветки и foo - это имя каталога, как я полагаю.

Изменить: (Удалена неработающая ссылка. См. комментарии.)

Ответ 4

Для определения <tree-ish> и <commit-ish> см. страницу git (1). Вам придется искать условия. В общем случае <tree-ish> означает ссылку на объект дерева git, но если вы передадите тип объекта, который ссылается на дерево (например, фиксация или ветвь), git будет автоматически использовать указанное дерево.

Ответ 5

Я новичок в управлении версиями и git. Это то, что я знаю. Деревом является структура файлов в репозитории. Это похоже на каталог в файловой системе. Смотрите - Какой инструмент git сгенерировал это древовидное представление?

Дерево-иш означает дерево. Он ссылается на часть или фиксацию дерева. Вы можете ссылаться на фиксацию, используя любой из них: полный или часть хэша SHA-1 для фиксации, указателя HEAD, ссылки на ветку, ссылки на тег. Другой метод использует любой из указанных методов вместе с предками или родителями фиксации. Пример предков: введите описание изображения здесь

Ответ 6

Из Git Glossary tree-ish is "Объект дерева или объект, который может быть рекурсивно разыменован в объекте дерева". commit, HEAD и tag являются примерами объектов из дерева.