Nettoyer les blobs inutilisés en utilisant git merge –squash suivi de git gc?

J'ai un repository qui est devenu très grand en raison d'un certain nombre de gros blobs qui ont été vérifiés il y a des années. Ils ont été supprimés lors des révisions ultérieures et ne sont plus nécessaires. Je devrais donc être en mesure de les supprimer maintenant.

J'ai vu quelques references à l'utilisation de git filter-branch mais utiliser cette command semble dangereux et kludgy, donc j'ai essayé ceci:

 git checkout --orphan new-master git rm -rf --cached * git merge --squash master git branch -D master git gc --prune=now 

Cela ne signifie-t-il pas que tout ce qui a été créé et supprimé à n'importe quel moment de l'histoire est définitivement supprimé?

Pour une raison quelconque, cela ne semble pas fonctionner – la taille est plus ou less la même.

Aucune suggestion?

Solutions Collecting From Web of "Nettoyer les blobs inutilisés en utilisant git merge –squash suivi de git gc?"

Désolé mais filter-branch est le seul moyen de le faire.

Vous devriez essayer de le tester dans un clone séparé de votre référentiel si vous vous sentez nerveux. Rappelez-vous simplement que git sauvegarde tout pour vous lorsque vous faites cela, donc votre repository cloné augmentera localement jusqu'à ce que vous poussez l'historique modifié.

Je voudrais vérifier la page utile de GitHub à ce sujet .

Aussi, si vous excusez ma prise éhontée, j'ai travaillé récemment sur une gemme de Ruby qui fournit des mesures de base sur les gros files à la fois dans votre historique et votre copy de travail. Il est encore en développement actif mais cela fonctionne et j'espère que vous le findez utile.

Edit: Pourquoi votre approche ne fonctionne pas

Tout d'abord, git est un système de contrôle de révision dissortingbué qui signifie que toutes les twigs et l'historique sont copiés localement lorsque vous faites un clone . Par conséquent, vous pouvez effectuer une git checkout <commit-sha> pour tout commit dans l'historique du repository afin d'get exactement ce à quoi ressemblait le repository à un moment donné dans le passé.

Créer une nouvelle twig ne vous libère pas de l'historique du référentiel; en fait, les twigs ne sont que des indicateurs de commits . Donc, pour simplifier, toutes les twigs ont une ascendance partagée, c'est pourquoi votre twig new-master est exactement la même que votre ancienne twig master . La petite diminution de la taille sera probablement due à une meilleure optimization de la garbage collection.

Lorsque vous avez exécuté git gc --prune=now , vous supprimiez simplement loose objects packfile c'est-à-dire les objects qui ne se packfile pas dans votre packfile . Un packfile est là où git stocke efficacement les objects afin d'augmenter l'efficacité et réduire la taille de votre repository. Vous pouvez find plus d'informations ici .

Il y a beaucoup à prendre en count si vous êtes un nouveau venu, mais j'ai essayé de donner un aperçu de haut niveau. J'explorerais l' excellente documentation de git et je me préparerais à éliminer cette command git filter-branch pour réellement réduire la taille de votre repository.