Ich bin sehr verwirrt darüber, wie man es benutzt git archive.

Ich habe ein Git-Repository mit den Ordnern Foo , Bar und Baz auf der obersten Ebene. Ich muss den Ordner Foo auf eine SVN-artige Weise exportieren , um eine schnelle Testbereitstellung zu ermöglichen.

Ich habe gelernt, dass ich git-archiveeine Art SVN-artigen Export verwenden kann .

Aber hier ist die Sache: Folgendes funktioniert gut:

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

es ergibt sich Foo , Bar , Baz Ordner im Zielordner.

Der folgende Fehler tritt jedoch auf fatal not a valid object name:

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

Die Dokumentation

Als Synopse für das git archiveProgramm sehe ich, dass es einen <tree-ish> [path]als Parameter annehmen kann (Synopse in relevanten Teilen zusammengefasst):

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

Wenn master/foo nicht tree-ish, was dann?

Die kurze Antwort (TL; DR)

"Tree-ish" ist ein Begriff, der sich auf einen Bezeichner bezieht (wie in der Dokumentation zu Git-Revisionen angegeben ), der letztendlich zu einem (Unter-) Verzeichnisbaum führt (Git bezeichnet Verzeichnisse als "Bäume" und "Baumobjekte").

Im Fall des Originalplakats handelt es sich foo um ein Verzeichnis , das er angeben möchte. Die korrekte Methode zum Angeben eines (Unter-) Verzeichnisses in Git ist die Verwendung dieser "baumartigen" Syntax (Element Nr. 15 aus der Git-Revisionsdokumentation ):

<rev>:<path>, Zum Beispiel HEAD:README, :README,master:./README

Ein Suffix :gefolgt von einem Pfad benennt den Blob oder Baum am angegebenen Pfad im baumartigen Objekt, das von dem Teil vor dem Doppelpunkt benannt wird.

Mit anderen Worten, master:fooist also die richtige Syntax, nicht master/foo.

Andere "Tree-ish" (Plus Commit-ish)

Hier ist eine vollständige Liste der Commit-ish- und Tree-ish-Bezeichner (aus der Git-Revisionsdokumentation , danke an LopSae für den Hinweis ):

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

Die Bezeichner Nr. 1-14 sind alle "Commit-ish", da sie alle zu Commits führen. Da Commits jedoch auch auf Verzeichnisbäume verweisen, führen sie letztendlich alle zu (Unter-) Verzeichnisbaumobjekten und können daher auch als "Baum" verwendet werden -ish ".

# 15 kann auch als Baum verwendet werden, wenn es sich auf ein (Unter-) Verzeichnis bezieht, aber es kann auch verwendet werden, um bestimmte Dateien zu identifizieren. Wenn es sich auf Dateien bezieht, bin ich mir nicht sicher, ob es immer noch als "baumartig" betrachtet wird oder ob es sich eher wie "blob-ish" verhält (Git bezeichnet Dateien als "blobs").

Die lange Antwort

Auf den niedrigsten Ebenen verfolgt Git den Quellcode mithilfe von vier grundlegenden Objekten:

1. Kommentierte Tags, die auf Commits verweisen.
2. Commits, die auf den Stammverzeichnisbaum Ihres Projekts verweisen.
3. Bäume, die Verzeichnisse und Unterverzeichnisse sind.
4. Blobs, die Dateien sind.

Jedes dieser Objekte hat seine eigene sha1-Hash-ID, da Linus Torvalds Git wie ein inhaltsadressierbares Dateisystem entworfen hat, dh Dateien können basierend auf ihrem Inhalt abgerufen werden (sha1-IDs werden aus Dateiinhalten generiert). Das Pro Git-Buch enthält dieses Beispieldiagramm :

Viele Git-Befehle können spezielle Bezeichner für Commits und (Unter-) Verzeichnisbäume akzeptieren:

• "Commit-ish" sind Bezeichner, die letztendlich zu einem Commit-Objekt führen. Beispielsweise,

  tag -> commit

• "Tree-ish" sind Bezeichner, die letztendlich zu Baumobjekten (dh Verzeichnisobjekten) führen.

  tag -> commit -> project-root-directory

Da Commit-Objekte immer auf ein Verzeichnisbaumobjekt (das Stammverzeichnis Ihres Projekts) verweisen, ist jeder Bezeichner, der "commit-ish" lautet, per Definition auch "tree-ish". Mit anderen Worten, jeder Bezeichner, der zu einem Festschreibungsobjekt führt, kann auch verwendet werden, um zu einem (Unter-) Verzeichnisbaumobjekt zu führen .

Da Verzeichnisbaumobjekte im Versionssystem von Git niemals auf Commits verweisen, kann nicht jeder Bezeichner, der auf einen (Unter-) Verzeichnisbaum verweist, auch verwendet werden, um auf ein Commit zu verweisen. Mit anderen Worten, die Menge der "Commit-ish" -Kennungen ist eine strikte Teilmenge der Menge der "Tree-ish" -Kennungen.

Wie in der Dokumentation erläutert ( danke an Trebor, der mir bei der Suche geholfen hat ):

<tree>

Gibt einen Baumobjektnamen an.

<commit>

Gibt einen Commit-Objektnamen an.

<tree-ish>

Gibt einen Baum-, Commit- oder Tag-Objektnamen an. Ein Befehl, der ein <tree-ish> Argument akzeptiert, möchte letztendlich ein <tree>Objekt bearbeiten, aber automatisch Dereferenzen <commit>und <tag>Objekte, die auf a zeigen <tree>.

<commit-ish>

Gibt einen Commit- oder Tag-Objektnamen an. Ein Befehl, der ein <commit-ish> Argument akzeptiert, möchte letztendlich ein <commit>Objekt bearbeiten <tag>, dereferenziert jedoch automatisch Objekte, die auf a zeigen <commit>.

Die Menge der baumartigen Bezeichner, die nicht als festgeschrieben werden können, sind

1. <rev>:<path>, was direkt zu Verzeichnisbäumen führt , keine Objekte festschreiben. Zum Beispiel HEAD:subdirectory.

2. Sha1-Bezeichner von Verzeichnisbaumobjekten .

Ein Baum ist eine Möglichkeit, einen bestimmten Baum zu benennen, der einer der folgenden sein kann:

• Referenzen wie:
  • KOPF
  • Stichworte
  • Filialnamen
  • Filialnamen mit Fernbedienungen, wie origin/somebranch
• Hash
• Kurze Hashes

Darüber hinaus kann jeder der oben genannten Punkte mit ^, ~. Referenzen können die @{}Notation auch für einige zusätzliche Funktionen verwenden:

• HEAD^oder HEAD^1wird an den ersten Elternteil von HEAD aufgelöst.
• HEAD^2 wird zum zweiten Elternteil aufgelöst
• HEAD^3wird zum dritten Elternteil und so weiter aufgelöst, was seltener ist und aus Verschmelzungen mit der Octopus-Strategie resultiert .
• HEAD~oder HEAD~1wird zum ersten Elternteil des Kopfes aufgelöst
• HEAD~2wird zum ersten Elternteil des ersten Elternteils von HEAD aufgelöst. Dies wäre das gleiche wieHEAD^^
• HEAD@{0} wird auf den aktuellen HEAD aufgelöst
• HEAD@{1}wird zum vorherigen Kopf aufgelöst. Dies kann nur von Referenzen verwendet werden, da das Referenzprotokoll verwendet wird. Bei HEADjedem Commit, Merge und Checkout wird der Wert von HEAD geändert und somit dem Protokoll hinzugefügt. git reflog HEADzeigt das Referenzprotokoll an, in dem Sie alle Bewegungen von HEAD sehen können und in was @{1}und so weiter aufgelöst wird.

Die meisten der oben weiter , so lange kombiniert werden , wie es sinnvoll , in Ihrem Repository macht, zum Beispiel: HEAD@{2}~3, somebranch^2~4, c00e66e~4^2, anotherbranch~^~^~^.

Jede der oben beschriebenen und ihre Kombinationen ist in der Dokumentation als baumartig gemeint. Dies ist nur eine Möglichkeit zu sagen, welcher Baum (oder welche Revision) für die meisten git-Befehle verwendet werden sollte.

Weitere Informationen unter Revisionsauswahl im Git-Buch .

Sie wollen wahrscheinlich

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

Der Ausdruck master/foomacht keinen Sinn: masterist ein Filialname und fooein Verzeichnisname, wie ich vermute.

Bearbeiten : (Defekter Link entfernt. Siehe Kommentare.)

Für Definitionen <tree-ish>und <commit-ish>finden Sie in der git (1) man - Seite. Sie müssen nach den Begriffen suchen. Im Allgemeinen <tree-ish>bedeutet dies einen Verweis auf ein Git-Baumobjekt. Wenn Sie jedoch einen Objekttyp übergeben, der auf einen Baum verweist (z. B. ein Commit oder eine Verzweigung), verwendet git automatisch den referenzierten Baum.

Ich bin ein Neuling in der Quellcodeverwaltung und Git. Das weiß ich. Ein Baum ist die Struktur von Dateien in einem Repository. Es ähnelt einem Verzeichnis in einem Dateisystem. Siehe - Welches Git-Tool hat diese Baumansicht generiert?

Baumartig bedeutet wie ein Baum. Es verweist auf einen Teil oder ein Commit eines Baums. Sie können auf ein Commit verweisen, indem Sie eines der folgenden Elemente verwenden: den SHA-1-Hash eines Commits, einen HEAD-Zeiger, eine Verzweigungsreferenz oder eine Tag-Referenz vollständig oder teilweise. Eine andere Methode verwendet eine der genannten Methoden zusammen mit Vorfahren oder Eltern eines Commits. Beispiel der Vorfahren:

Aus dem Git-Glossar ist tree-ish "Ein Baumobjekt oder ein Objekt, das rekursiv auf ein Baumobjekt dereferenziert werden kann." Commit, HEAD und Tag sind Beispiele für baumartige Objekte.