J'ai nettoyé le dépôt Git (cloud Bitbucket) avec bfg, mais le dernier commit est resté non nettoyé (comme écrit dans la documentation bfg: Par défaut, le BFG ne modifie pas le contenu de votre dernier commit sur votre master (ou 'HEAD '), même s'il nettoiera tous les commits précédents.).
Cependant, je ne l'ai pas vu et je voulais exécuter git gc dans un Bitbucket.
Pour cela, j'ai fait " git reset --hard HEAD " et je suis revenu dessus puis " git push --force ".
Mais la taille du dépôt a augmenté?!
Maintenant, j'ai ce commit avec l'ancien historique laissé dans le dépôt, et bfg ne peut pas le nettoyer, que dois-je faire?
Comment puis-je le supprimer, car il n'est plus attaché à l'arborescence de travail?
3 Réponses :
Vous pouvez dire à BFG de modifier également le dernier commit avec l'indicateur --no-blob-protection . * (Ceci provient de la documentation BFG-Repo-Cleander).
Vous pouvez également créer un nouveau commit qui supprime le mauvais fichier, puis exécutez BFG normalement.
J'ai essayé de le faire, mais le commit n'est plus dans l'arbre de travail et le bfg ne le voit pas
Réessayez, cette fois en utilisant newren / git-filter-repo code > , qui remplacera BFG et git filter-branch
Comme mentionné dans sa documentation: p>
[il y a] des étapes supplémentaires pour supprimer les autres balises et faire un autre gc sont toujours nécessaires pour nettoyer les anciens objets et éviter de mélanger le nouvel et l'ancien historique avant de pousser quelque part
git filter-repo évite de confondre les utilisateurs (et empêche de repousser accidentellement d'anciens éléments) en raison du mélange de l'ancien référentiel et du référentiel réécrit.
Remarque: du côté serveur (c'est-à-dire vers lequel vous poussez), un git gc doit être exécuté, ce qui est fait régulièrement mais pas immédiatement.
C'est le cas de GitHub , ainsi que de BitBucket.
Voir la documentation Atlassian " Comment réaliser un manuel garbage collection sur un référentiel "
Bitbucket implémente sa propre logique de garbage collection sans s'appuyer plus sur
git gc(ceci est réalisé en définissant [gc] auto = 0 sur tous les référentiels).
Lorsqu'un fork est créé, le pruneexpire = never est ajouté à la configuration git et il est supprimé lorsque le dernier fork est supprimé.
Comme mentionné ici :
BitBucket exécutera
git gceux-mêmes en réponse àgit reset --hard HEAD ~ 1(qui annule le dernier commit) suivi degit push -f.
Donc dans votre cas:
git commit --allow-empty -m "empty commit" git push git reflog expire --expire-unreachable="30m" --all git prune --expire="30m" -v git gc --prune="30m" git reset --hard HEAD~1 git push -f
Et un git gc devrait être fait côté BitBucket!
J'ai écrit avec le support bitbucket, ils ont exécuté le script "git gc" sur le serveur et l'ancienne histoire a été nettoyée
Vous devriez pouvoir déclencher un git gc côté BitBucket (sans avoir à les contacter). Voir ma réponse modifiée .
Je sais, je l'ai fait, ça ne m'a pas aidé
Le support Bitbucket pourrait avoir des réponses sur les raisons pour lesquelles leur propre processus n'a pas déclenché un git gc .