Jestem bardzo zdezorientowany, jak używać git archive.

Mam repozytorium git z folderami Foo , Bar i Baz na najwyższym poziomie. Muszę wyeksportować folder Foo w sposób podobny do SVN, aby szybko przeprowadzić test.

Dowiedziałem się, że mogę użyć git-archivew eksportowej formie SVN .

Ale oto rzecz, następujące działa dobrze:

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

powoduje to foldery Foo , Bar , Baz w folderze docelowym .

Jednak następujące błędy wystąpią z fatal not a valid object name:

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

Dokumentacja

Patrząc na streszczenie git archiveprogramu widzę, że może on przyjąć <tree-ish> [path]jako parametr (streszczenie podsumowane w odpowiednich częściach):

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

Jeśli master/foo nie tree-ish, to co jest?

Krótka odpowiedź (TL; DR)

„Drzewo” to termin odnoszący się do dowolnego identyfikatora (określonego w dokumentacji wersji Git ), który ostatecznie prowadzi do (pod) drzewa katalogów (Git określa katalogi jako „drzewa” i „obiekty drzew”).

W przypadku oryginalnego plakatu foo jest to katalog , który chce określić. Prawidłowym sposobem określenia (pod) katalogu w Git jest użycie składni "drzewa" (punkt # 15 z dokumentacji wersji Git ):

<rev>:<path>Np HEAD:README, :README,master:./README

Sufiks, :po którym następuje ścieżka, określa obiekt blob lub drzewo w podanej ścieżce w obiekcie drzewa nazwanym przez część przed dwukropkiem.

Innymi słowy, master:footo poprawna składnia, a nie master/foo.

Inne „Tree-ish” (Plus Commit-ish)

Oto pełna lista identyfikatorów zatwierdzeń i drzew (z dokumentacji wersji Git , dzięki LopSae za wskazanie ):

----------------------------------------------------------------------
|    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
----------------------------------------------------------------------

Identyfikatory # 1-14 są wszystkie „zatwierdzone”, ponieważ wszystkie prowadzą do zatwierdzeń, ale ponieważ zatwierdzenia wskazują również drzewa katalogów, wszystkie ostatecznie prowadzą do obiektów (pod) drzewa katalogów i dlatego mogą być również używane jako „drzewo -ish ”.

Numer 15 może być również używany jako drzewo, gdy odnosi się do (pod) katalogu, ale może być również używany do identyfikowania określonych plików. Kiedy odnosi się do plików, nie jestem pewien, czy nadal jest uważany za „drzewo-ish”, czy działa bardziej jak „blob-ish” (Git określa pliki jako „bloby”).

Długa odpowiedź

Na najniższych poziomach Git śledzi kod źródłowy przy użyciu czterech podstawowych obiektów:

1. Tagi z adnotacjami, które wskazują na zatwierdzenia.
2. Commits, które wskazują drzewo katalogów głównych projektu.
3. Drzewa, które są katalogami i podkatalogami.
4. Obiekty BLOB, które są plikami.

Każdy z tych obiektów ma swój własny identyfikator hash sha1, ponieważ Linus Torvalds zaprojektował Gita jako system plików z adresowaniem treści , tj. Pliki mogą być pobierane na podstawie ich zawartości (identyfikatory sha1 są generowane z zawartości pliku). Książka Pro Git zawiera przykładowy diagram :

Wiele poleceń Git może akceptować specjalne identyfikatory dla zatwierdzeń i (pod) drzew katalogów:

• „Commit-ish” to identyfikatory, które ostatecznie prowadzą do obiektu zatwierdzenia. Na przykład,

  tag -> commit

• „Drzewo” to identyfikatory, które ostatecznie prowadzą do obiektów drzewiastych (tj. Katalogów).

  tag -> commit -> project-root-directory

Ponieważ obiekty zatwierdzone zawsze wskazują na obiekt drzewa katalogów (katalog główny projektu), każdy identyfikator, który jest „zatwierdzony”, jest z definicji również „drzewem”. Innymi słowy, każdy identyfikator prowadzący do obiektu zatwierdzenia może być również użyty do wskazania obiektu drzewa (pod) katalogu .

Ale ponieważ obiekty drzewa katalogów nigdy nie wskazują zatwierdzeń w systemie kontroli wersji Gita, nie każdy identyfikator wskazujący na (pod) drzewo katalogów może być również użyty do wskazania zatwierdzenia. Innymi słowy, zestaw identyfikatorów „zatwierdzonych” jest ścisłym podzbiorem zbioru identyfikatorów „drzewiastych”.

Jak wyjaśniono w dokumentacji ( dzięki Treborowi za pomoc w znalezieniu ):

<tree>

Wskazuje nazwę obiektu drzewa.

<commit>

Wskazuje nazwę obiektu zatwierdzenia.

<tree-ish>

Wskazuje nazwę obiektu drzewa, zatwierdzenia lub znacznika. Polecenie, które <tree-ish> ostatecznie pobiera argument, chce operować na <tree>obiekcie, ale automatycznie wyłuskuje <commit>i <tag>obiekty, które wskazują na a <tree>.

<commit-ish>

Wskazuje nazwę obiektu zatwierdzenia lub znacznika. Polecenie, które <commit-ish> ostatecznie pobiera argument, chce operować na <commit>obiekcie, ale automatycznie wyłuskuje <tag>obiekty, które wskazują na a <commit>.

Zestaw drzew-owski identyfikatorów, które nie mogą być stosowane jako popełnić-owski są

1. <rev>:<path>, co prowadzi bezpośrednio do drzew katalogów, a nie do zatwierdzania obiektów. Na przykład HEAD:subdirectory.

2. Identyfikatory Sha1 obiektów drzewa katalogów .

Drzewo to sposób na nazwanie konkretnego drzewa, który może być jednym z następujących:

• Referencje, takie jak:
  • GŁOWA
  • Tagi
  • Nazwy oddziałów
  • Nazwy oddziałów z pilotami, takie jak origin/somebranch
• Haszysz
• Krótkie skróty

Na początku, że każdy z powyższych może być dodawana ^, ~. W odwołaniach można również używać @{}notacji dla niektórych dodatkowych funkcji:

• HEAD^lub HEAD^1zostanie zamieniony na pierwszego rodzica HEAD.
• HEAD^2 zdecyduje się na drugiego rodzica
• HEAD^3zdecyduje się na trzeciego rodzica i tak dalej, co jest rzadsze i jest wynikiem połączenia ze strategią ośmiornicy .
• HEAD~lub HEAD~1zdecyduje się na pierwszego rodzica głowy
• HEAD~2rozwiąże się do pierwszego rodzica pierwszego rodzica HEAD. To byłoby to samo coHEAD^^
• HEAD@{0} rozwiąże się do bieżącego HEAD
• HEAD@{1}rozwiąże się do poprzedniej głowy. Może to być używane tylko przez odwołania, ponieważ korzysta z dziennika odniesień. W przypadku HEADkażdego zatwierdzenia, merge, checkout zmieni wartość HEAD i tym samym doda ją do dziennika. git reflog HEADwyświetli dziennik odniesienia, w którym możesz zobaczyć wszystkie ruchy HEAD i prawidłowo, co @{1}i tak dalej się rozwiąże.

Większość z powyższych może być dodatkowo połączone tak długo, jak to ma sens w swoim repozytorium, na przykład: HEAD@{2}~3, somebranch^2~4, c00e66e~4^2, anotherbranch~^~^~^.

Tak więc każda z opisanych powyżej kombinacji i jej kombinacje są w dokumentacji rozumiane jako drzewo, które jest tylko sposobem na określenie, które drzewo (lub wersja) jest tym, które powinno być używane dla większości poleceń git.

Więcej informacji w sekcji Wybór wersji w książce Git .

Prawdopodobnie chcesz

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

Wyrażenie master/foonie ma sensu: masterjest nazwą gałęzi i foojest nazwą katalogu, jak przypuszczam.

Edytuj : (Usunięto uszkodzony link. Zobacz komentarze.)

Definicje <tree-ish>i <commit-ish>zobacz stronę podręcznika git (1) . Będziesz musiał wyszukać terminy. Ogólnie <tree-ish>oznacza odniesienie do obiektu drzewa git, ale jeśli przekażesz typ obiektu, który odwołuje się do drzewa (na przykład zatwierdzenie lub gałąź), git automatycznie użyje drzewa, do którego się odwołuje.

Jestem nowicjuszem w kontroli źródła i Git. To jest to, co wiem. Drzewo to struktura plików w repozytorium. Jest podobny do katalogu w systemie plików. Zobacz - Które narzędzie git wygenerowało ten widok drzewa?

Drzewo znaczy jak drzewo. Odnosi się do części lub zatwierdzenia drzewa. Możesz odwołać się do zatwierdzenia, używając jednego z nich: pełnego lub części skrótu SHA-1 zatwierdzenia, wskaźnika HEAD, odniesienia do gałęzi, odniesienia do znacznika. Inna metoda wykorzystuje dowolną z wymienionych metod wraz z przodkami lub rodzicami zatwierdzenia. Przykład przodków:

W glosariuszu Git drzewo-ish brzmi: „Obiekt drzewa lub obiekt, który może być rekursywnie dereferencjonowany do obiektu drzewa”. commit, HEAD i tag to przykłady obiektów drzewiastych.