Git ne jette pas d'informations par lui-même *. Toutes les versions précédentes de chaque fichier sont toujours disponibles pour les révisions, les différences, les inspections, etc.
Arborescence complète versus fichiers individuels
Ce que vous essayez peut-être de réconcilier, c'est l'idée d'accéder à une ancienne version d'un fichier individuel par rapport au fait que le modèle d'historique de Git se concentre sur l'ensemble de l'arborescence. Le versionnage d'arbre entier nécessite un peu plus de travail pour voir (par exemple) la version foo.ctelle qu'elle existait il y a dix foo.cchangements par rapport à dix changements d'arbre entier:
# 10 foo.c-changes ago
git show $(git rev-list -n 10 --reverse HEAD -- foo.c | head -1):foo.c
# 10 whole-tree-changes ago
git show HEAD~10:foo.c
Les avantages de l'orientation arborescente, principalement la possibilité de visualiser les validations comme une unité de modifications interdépendantes apportées à diverses parties de l'arbre entier, l'emportent largement sur la saisie supplémentaire (qui peut être atténuée avec des alias, des scripts, etc.) et le temps CPU passé à fouiller dans les commits passés.
Efficacité de stockage
Lorsqu'un nouvel objet (par exemple un fichier avec un contenu précédemment invisible) entre dans le système, il est stocké avec une compression simple (zlib) en tant qu '«objet lâche». Lorsque suffisamment d'objets en vrac s'accumulent (en fonction de l' gc.autooption de configuration; ou lorsque l'utilisateur exécute git gc ou l'une des commandes d'emballage de niveau inférieur), Git collectera de nombreux objets en vrac dans un seul "fichier de pack".
Les objets d'un fichier pack peuvent être stockés sous forme de données compressées simples (identiques à un objet lâche, simplement regroupées avec d'autres objets) ou sous forme de deltas compressés contre un autre objet. Les deltas peuvent être enchaînés ensemble à des profondeurs configurables ( pack.depth) et peuvent être créés par rapport à n'importe quel objet approprié ( pack.windowcontrôle l'étendue de la recherche par Git de la meilleure base delta; une version d'un fichier historiquement indépendant peut être utilisée comme base si cela produirait un bonne compression delta). La latitude que confèrent les configurations de profondeur et de taille de fenêtre au moteur de compression delta se traduit souvent par une meilleure compression delta que la compression simple «diff» d'une version contre la version suivante / précédente de style CVS.
C'est cette compression delta agressive (combinée à la compression zlib normale) qui peut souvent laisser un référentiel Git (avec l'historique complet et une arborescence de travail non compressée) prendre moins d'espace qu'une seule extraction SVN (avec une arborescence de travail non compressée et une copie vierge).
Voir les sections Comment Git stocke les objets et Les sections Packfile du Git Community Book . Également la page de manuel git pack-objects .
* Vous pouvez dire à Git de supprimer les commits en «réécrivant l'historique» et avec des commandes comme git reset , mais même dans ces cas, Git «s'accroche» aux commits nouvellement supprimés pendant un certain temps, juste au cas où vous décideriez que vous en avez besoin. Voir git reflog et git prune .