Je ne sais pas trop comment l'utiliser git archive.

J'ai un référentiel git avec le dossier Foo , Bar et Baz au niveau supérieur. J'ai besoin d'exporter le dossier Foo d'une manière SVN-ish pour un déploiement de test rapide.

J'ai appris que je pouvais utiliser git-archiveune sorte d'exportation SVN-ish .

Mais voici la chose, ce qui suit fonctionne bien:

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

il en résulte des dossiers Foo , Bar , Baz dans le dossier de destination .

Cependant, ce qui suit sera une erreur avec fatal not a valid object name:

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

La documentation

En regardant le synopsis du git archiveprogramme, je vois qu'il peut prendre un <tree-ish> [path]comme paramètre (synopsis résumé aux parties pertinentes):

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

Si master/foo non tree-ish, qu'est-ce que c'est?

La réponse courte (TL; DR)

"Tree-ish" est un terme qui fait référence à tout identifiant (comme spécifié dans la documentation des révisions de Git ) qui mène finalement à une (sous) arborescence de répertoires (Git se réfère aux répertoires comme des "arbres" et des "objets d'arborescence").

Dans le cas de l'affiche d'origine, foo c'est un répertoire qu'il souhaite spécifier. La manière correcte de spécifier un (sous) répertoire dans Git est d'utiliser cette syntaxe "tree-ish" (élément n ° 15 de la documentation des révisions Git ):

<rev>:<path>, Par exemple HEAD:README, :README,master:./README

Un suffixe :suivi d'un chemin nomme l'objet blob ou l'arborescence au chemin donné dans l'objet arborescent nommé par la partie avant les deux-points.

Donc, en d'autres termes, master:foola syntaxe est correcte, non master/foo.

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

Voici une liste complète des identifiants commit-ish et tree-ish (de la documentation des révisions Git , merci à LopSae pour l'avoir signalé ):

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

Les identifiants # 1-14 sont tous "commit-ish", car ils mènent tous à des commits, mais comme les commits pointent également vers des arborescences de répertoires, ils mènent tous finalement à des objets d'arborescence de (sous) répertoires, et peuvent donc également être utilisés comme "arborescence" -ish ".

# 15 peut également être utilisé comme arborescence quand il fait référence à un (sous) répertoire, mais il peut également être utilisé pour identifier des fichiers spécifiques. Quand il fait référence à des fichiers, je ne suis pas sûr s'il est toujours considéré comme "tree-ish", ou s'il agit plus comme "blob-ish" (Git se réfère aux fichiers comme "blobs").

La longue réponse

À ses niveaux les plus bas, Git assure le suivi du code source à l'aide de quatre objets fondamentaux:

1. Balises annotées, qui pointent vers des commits.
2. Commits, qui pointent vers l'arborescence de répertoires racine de votre projet.
3. Les arbres, qui sont des répertoires et des sous-répertoires.
4. Blobs, qui sont des fichiers.

Chacun de ces objets a son propre ID de hachage sha1, puisque Linus Torvalds a conçu Git comme un système de fichiers adressable par le contenu , c'est-à-dire que les fichiers peuvent être récupérés en fonction de leur contenu (les ID sha1 sont générés à partir du contenu du fichier). Le livre Pro Git donne cet exemple de diagramme :

De nombreuses commandes Git peuvent accepter des identificateurs spéciaux pour les commits et les arborescences de (sous) répertoires:

• "Commit-ish" sont des identificateurs qui mènent finalement à un objet de commit. Par exemple,

  tag -> commit

• "Tree-ish" sont des identifiants qui mènent finalement à des objets d'arborescence (ie répertoire).

  tag -> commit -> project-root-directory

Étant donné que les objets de validation pointent toujours vers un objet d'arborescence de répertoires (le répertoire racine de votre projet), tout identificateur qui est "commit-ish" est, par définition, également "tree-ish". En d'autres termes, tout identifiant menant à un objet de validation peut également être utilisé pour conduire à un objet d'arborescence de (sous) répertoires .

Mais comme les objets d'arborescence de répertoires ne pointent jamais vers des commits dans le système de gestion des versions de Git, tous les identificateurs qui pointent vers une (sous) arborescence de répertoires ne peuvent pas également être utilisés pour pointer vers un commit. En d'autres termes, l'ensemble des identifiants «commit-ish» est un sous-ensemble strict de l'ensemble des identifiants «tree-ish».

Comme expliqué dans la documentation ( merci à Trebor de m'avoir aidé à le trouver ):

<tree>

Indique un nom d'objet d'arborescence.

<commit>

Indique un nom d'objet de validation.

<tree-ish>

Indique un nom d'objet d'arborescence, de validation ou de balise. Une commande qui prend un <tree-ish> argument veut finalement opérer sur un <tree>objet mais déréférence automatiquement <commit>et les <tag>objets qui pointent vers un <tree>.

<commit-ish>

Indique un nom d'objet de validation ou de balise. Une commande qui prend un <commit-ish> argument veut finalement opérer sur un <commit>objet mais déréférence automatiquement les <tag>objets qui pointent vers un <commit>.

L'ensemble des identificateurs d'arborescence qui ne peuvent pas être utilisés comme commit-ish sont

1. <rev>:<path>, qui mène directement aux arborescences de répertoires, pas aux objets de validation. Par exemple HEAD:subdirectory,.

2. Identifiants Sha1 des objets de l' arborescence de répertoires .

Un tree-ish est une façon de nommer un arbre spécifique qui peut être l'un des suivants:

• Références comme:
  • TÊTE
  • Mots clés
  • Noms des succursales
  • Noms de succursales avec télécommandes, comme origin/somebranch
• Hacher
• Hachages courts

En plus de cela, tout de ce qui précède peut être joint en annexe avec ^, ~. Les références peuvent également utiliser la @{}notation pour certaines fonctionnalités supplémentaires:

• HEAD^ou HEAD^1sera résolu au premier parent de HEAD.
• HEAD^2 se résoudra au deuxième parent
• HEAD^3se résoudra au troisième parent et ainsi de suite, qui est plus rare et produit des fusions avec la stratégie de poulpe .
• HEAD~ou HEAD~1se résoudra au premier parent de la tête
• HEAD~2se résoudra au premier parent du premier parent de HEAD. Ce serait la même chose queHEAD^^
• HEAD@{0} se résoudra à la tête actuelle
• HEAD@{1}se résoudra à la tête précédente. Cela ne peut être utilisé que par des références car il utilise le journal de référence. Dans le cas de HEADchaque commit, fusion, checkout changera la valeur de HEAD et l'ajoutera ainsi au journal. git reflog HEADaffichera le journal de référence où vous pouvez voir tous les mouvements de HEAD et correctement ce à quoi @{1}et ainsi de suite résoudra.

La plupart de ce qui précède peut être combiné tant qu'il est logique dans votre référentiel, par exemple: HEAD@{2}~3, somebranch^2~4, c00e66e~4^2, anotherbranch~^~^~^.

Donc, tout ce qui est décrit ci-dessus, et ses combinaisons, est ce que la documentation entend par arborescence, qui est juste un moyen de dire quel arbre (ou révision) est celui qui devrait être utilisé pour la plupart des commandes git.

Plus d'informations dans Revision Selection dans le livre Git .

Tu veux probablement

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

L'expression master/foon'a pas de sens: masterest un nom de branche et fooest un nom de répertoire, comme je le suppose.

Modifier : (Suppression du lien rompu. Voir les commentaires.)

Pour obtenir les définitions <tree-ish>et <commit-ish>consulter la page de manuel git (1) . Vous devrez rechercher les termes. En général, cela <tree-ish>signifie une référence à un objet d'arborescence git, mais si vous passez un type d'objet qui fait référence à un arbre (tel qu'un commit ou une branche), git utilisera automatiquement l'arborescence référencée.

Je suis un débutant en contrôle de code source et en git. Voilà ce que je sais. Une arborescence est la structure des fichiers dans un référentiel. C'est similaire à un répertoire dans un système de fichiers. Voir - Quel outil git a généré cette arborescence?

Tree-ish signifie comme un arbre. Il fait référence à une partie ou à un commit d'un arbre. Vous pouvez référencer un commit en utilisant l'un de ces éléments: tout ou partie du hachage SHA-1 d'un commit, pointeur HEAD, référence de branche, référence de balise. Une autre méthode utilise l'une des méthodes mentionnées avec les ancêtres ou les parents d'un commit. Exemple d'ancêtres:

De Git Glossary tree-ish est "Un objet d'arbre ou un objet qui peut être déréférencé récursivement à un objet d'arbre." commit, HEAD et tag sont des exemples d'objets arborescents.