Я дуже розгублений у тому, як користуватися 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, то що таке?

Короткий відповідь (TL; DR)

«Дерево-МІГ» це термін , який відноситься до будь-якого ідентифікатора (як зазначено в переглядах документації Git ) , що в кінцевому рахунку призводить до (суб) дереву каталогів (Гіт відноситься до каталогів , як «дерева» і «дерево об'єкти»).

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

<rev>:<path>, Наприклад HEAD:README, :README,master:./README

Суфікс, :за яким слідує шлях, називає крапку або дерево на заданому шляху в об'єкті дерева, названому частиною перед двокрапкою.

Отже, іншими словами, 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 - це "фікш-іш", тому що всі вони призводять до комітів, а оскільки комісії також вказують на дерева каталогів, вони в кінцевому підсумку призводять до (під) об'єктів дерева каталогів, і тому можуть також використовуватися як "дерево" -ш ».

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

Довга відповідь

На найнижчих рівнях Git відстежує вихідний код за допомогою чотирьох основних об'єктів:

1. Помічені теги, які вказують на коміти.
2. Коміти, які вказують на дерево кореневих каталогів вашого проекту.
3. Дерева - це каталоги та підкаталоги.
4. Краплі, які є файлами.

Кожен з цих об'єктів має свій ідентифікатор sha1 хеша, оскільки Лінус Торвальдс розробив Git як файлову систему, адресовану вмістом, тобто файли можна отримати на основі їх вмісту (ша1 ідентифікатори генеруються з вмісту файлу). У книзі Pro Git наведено такий приклад діаграми :

Багато команд Git можуть приймати спеціальні ідентифікатори для команд і дерев (під) каталогів:

• "Здійснення результатів" - це ідентифікатори, які в кінцевому підсумку призводять до об'єкта комісії. Наприклад,

  tag -> commit

• "Дерево-іш" - це ідентифікатори, які в кінцевому підсумку призводять до деревним (тобто директорійним) об'єктам.

  tag -> commit -> project-root-directory

Оскільки об'єкти фіксації завжди вказують на об'єкт дерева каталогів (кореневий каталог вашого проекту), будь-який ідентифікатор, який є "виконувати-іш", за визначенням також є "деревом-іш". Іншими словами, будь-який ідентифікатор, який призводить до об’єкта фіксації, також може бути використаний для ведення до (суб) об’єкта дерева каталогу .

Але оскільки об'єкти дерева каталогів ніколи не вказують на коміти в системі версій Git, не кожен ідентифікатор, який вказує на (під) дерево каталогів, також може використовуватися для вказівки на фіксацію. Іншими словами, набір ідентифікаторів "виконувати іш" є суворим підмножиною набору ідентифікаторів "дерево-іш".

Як пояснено в документації ( дякую Требору за те, що він мені допомагав знайти ):

<tree>

Вказує назву об'єкта дерева.

<commit>

Вказує ім'я об'єкта фіксації.

<tree-ish>

Вказує ім'я дерева, фіксування або тегу. Команда, яка приймає <tree-ish> аргумент, врешті-решт хоче оперувати <tree>об’єктом, але автоматично перенаправляє <commit>та <tag>об'єкти, які вказують на a <tree>.

<commit-ish>

Вказує ім'я об'єкта чи тегу. Команда, яка приймає <commit-ish> аргумент, в кінцевому підсумку хоче оперувати <commit>об'єктом, але автоматично відмежувати <tag>об'єкти, які вказують на a <commit>.

Набір ідентифікаторів дерева-ish, які не можуть бути використані як виконувати результати, є

1. <rev>:<path>, що веде безпосередньо до дерев каталогів, а не здійснює об'єкти. Наприклад, HEAD:subdirectory.

2. Ідентифікатори Sha1 об'єктів дерева каталогів .

Дерево-ish - це спосіб назви конкретного дерева, який може бути одним із наступних:

• Список літератури, як:
  • ГОЛОВА
  • Теги
  • Назви галузей
  • Назви гілок з дистанційними, як origin/somebranch
• Хеш
• Короткі хеши

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

• HEAD^або HEAD^1буде вирішено для першого батька HEAD.
• HEAD^2 вирішиться до другого з батьків
• HEAD^3вирішиться до третього батька і так далі, що є більш рідкісним і продуктом злиття зі стратегією восьминога .
• HEAD~або HEAD~1вирішиться до першого батька голови
• HEAD~2вирішиться до першого батька першого батька HEAD. Це було б те саме, щоHEAD^^
• HEAD@{0} вирішиться до поточної ГЛАВИ
• HEAD@{1}вирішиться до попереднього керівника. Це можуть бути використані лише посилання, оскільки він використовує довідковий журнал. У випадку HEADкожної комісії , злиття, замовлення змінить значення HEAD і тим самим додасть його до журналу. git reflog HEADвідобразиться довідковий журнал, де ви зможете побачити всі рухи HEAD і правильно, що @{1}і так далі буде вирішено.

Більшість з перерахованого вище може бути додатково об'єднані до тих пір , як це має сенс у вашому сховищі, наприклад: HEAD@{2}~3, somebranch^2~4, c00e66e~4^2, anotherbranch~^~^~^.

Отже, будь-яке з описаних вище та його комбінацій - це те, що в документації позначається як дерево-ish, що є лише способом сказати, яке дерево (або редакція) є тим, яке слід використовувати для більшості команд git.

Детальніше у підбірці до редакції у книзі Git .

Ви, мабуть, хочете

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

Вираз master/fooне має сенсу: masterце ім'я гілки та fooє ім'ям каталогу, як я припускаю.

Редагувати : (Видалено пошкоджене посилання. Див. Коментарі.)

Для визначення <tree-ish>та <commit-ish>перегляньте сторінку чоловіка git (1) . Вам доведеться шукати терміни. Загалом <tree-ish>означає посилання на об’єкт дерева git, але якщо ви передасте тип об'єкта, на який посилається дерево (наприклад, коміт або гілка), git автоматично використовуватиме посилане дерево.

Я новачок у керуванні джерелами та git. Це я знаю. Дерево - це структура файлів у сховищі. Його схоже на каталог у файловій системі. Подивіться - Який інструмент git створив цей вид дерева?

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

З Git Glossary tree-ish - це "Дерево об'єкт або об'єкт, який може бути рекурсивно перенесений на деревний об'єкт". commit, HEAD і тег - приклади дерев яних об'єктів.