Le scénario
Imaginez que je sois obligé de travailler avec certains de mes fichiers toujours stockés à l'intérieur. .zip
fichiers. Certains des fichiers contenus dans le fichier ZIP sont de petits fichiers texte et changent souvent, tandis que d'autres sont plus volumineux mais heureusement plutôt statiques (par exemple, des images).
Si je veux placer ces fichiers ZIP à l'intérieur d'un dépôt Git, chaque ZIP est traité comme un blob, donc à chaque fois que je fais un commit, le dépôt augmente de la taille du fichier ZIP... même si seulement un petit fichier texte à l'intérieur a changé !
Pourquoi c'est réaliste
Microsoft Word 2007 / 2010 .docx
et Excel .xlsx
sont des fichiers ZIP...
Ce que je veux
Existe-t-il, par hasard, un moyen d'indiquer à Git de ne pas traiter les fichiers ZIP comme des fichiers, mais plutôt comme des répertoires et de traiter leur contenu comme des fichiers ?
Les avantages
- une taille de référentiel beaucoup plus petite, c'est-à-dire des transferts/sauvegardes plus rapides.
- Afficher les modifications apportées par Git aux fichiers ZIP fonctionnerait automatiquement
Mais ça ne pourrait pas marcher, dites-vous ?
Je me rends compte que sans métadonnées supplémentaires, cela conduirait à une certaine ambiguïté : sur un fichier git checkout
Git devrait décider s'il faut créer foo.zip/bar.txt
comme un fichier dans un répertoire ordinaire ou un fichier ZIP. Cependant, cela pourrait être résolu par des options de configuration, je pense.
Deux idées sur la façon dont cela pourrait être fait (s'il n'existe pas encore)
- en utilisant une bibliothèque telle que
minizip
oIO::Compress::Zip
dans Git - ajouter d'une manière ou d'une autre une couche de système de fichiers de sorte que Git voit réellement les fichiers ZIP comme des répertoires au départ
2 votes
Le scénario avec
.docx
a du sens, mais dans de nombreux autres cas, vous pourriez envisager de suivre les fichiers individuels normalement avec git et seulement bâtiment le résultat.zip
en utilisant un outil de construction approprié commemake
.2 votes
Si l'on considère que deux fichiers zip qui semblent différents l'un de l'autre peuvent contenir exactement les mêmes données (par exemple un fichier texte zippé deux fois avec deux niveaux de compression différents), cela devient beaucoup plus délicat. S'il est facile de représenter la différence entre les deux versions des fichiers décompressés avec peu d'informations, je suppose que représenter la différence entre les deux versions de l'archive (ce qui est essentiellement ce que git doit faire) avec à peu près aussi peu d'informations serait non trivial.
0 votes
Avez-vous jamais abouti à une solution mise en œuvre de Réponse de Jeff ou autre chose ? Je me demande à peu près la même chose, sauf que pour les archives tar ce qui devrait donner une réponse compatible...
0 votes
L'outil de conception de l'information (IDT) de SAP crée une structure de fichier similaire pour son système de gestion de l'information.
UNX
format. Il est également récursif : il contient un fichierBLX
et un fichierDFX
qui sont tous deux des archives, correspondant respectivement à la "couche métier" et à la "fondation de données". J'aimerais également avoir une solution.0 votes
Le VCS intégré de Jetbrains vous permet de regarder à l'intérieur des fichiers de type zip. C'est très utile, mais cela vous oblige à revoir, par exemple, les PRs dans l'IDE. Maintenant que Microsoft a pris le relais, nous pourrions voir cela dans le diff pr de github également.