Je sais que dans Mercurial, "l'histoire est sacrée".
Mais disons que quelqu'un commet accidentellement quelque chose qu'ils ne devraient pas, comme un fichier de paramètres contenant un mot de passe ou quelque chose. Disons même des passages de temps avant que quiconque la réalise, alors sa pendaison de plusieurs commits. Évidemment, le découvreur supprime ensuite les données sensibles du référentiel.
Y a-t-il un moyen de frotter de manière permanente ce fichier ou les données sensibles de l'historique de validation, comme s'il n'existait jamais? Ou ces données sensibles seraient-elles simplement une partie permanente du repo pour toujours et jamais?
4 Réponses :
Il y a quelques méthodes pour accomplir cela. Tous ont besoin de la coopération de tous ceux qui ont cloné votre référentiel ou ont tiré des modifications à partir de celui-ci après l'introduction du changement.
Quelle méthode à utiliser dépend de la nature exacte des données engagées et de l'endroit dans l'histoire. Tous nécessitent l'utilisation des extensions mercuriales et ne peuvent pas être accomplies avec du cœur mercurial. Heureusement, toutes les extensions requises sont expédiées par défaut avec Mercurial et doivent simplement être activées.
Je ne vais pas en détail sur les méthodes ici car il existe plusieurs réponses qui donnent des méthodes différentes dans la question, c'est une dupe de. Je veux juste être clair que la réponse acceptée dans cette question est techniquement correcte, mais pas utile. C'est en fait possible.
Je n'ai pas étudié les détails de la façon dont les crochets fonctionnent donc cette idée ne peut pas jouer pleinement. Il peut être possible de configurer des crochets pour interdire la validation, la poussée et la tirage de vos fichiers sensibles. Il y a des crochets qui vont courir avant de commettraliser ou de pousser ( pré-upommit et pré-voyant ). Protéger les crochets afin qu'ils ne soient pas contournés est un autre problème qui
Non. Pas vraiment. Si vous pouvez convaincre tous ceux qui ont eu accès à Supprimer et à reclones, vous pouvez supprimer le fichier de l'accès futur.
Mais si vous, par exemple, a poussé votre mot de passe root à un repo-bitbucket public -? Vous devriez le changer. Votre information est maintenant publique et fuite et devrait être considérée comme telle. Désolé.
Si, et seulement si, ce référentiel Communalement, nous trouvons quelque chose lorsque nous audons le référentiel avant de publier ou de livrer à un client, tel qu'un fichier web.config ou ini avec un mot de passe. P> L'extension n'est pas activée par défaut, mais est incluse avec tous les clients que j'utilise, vous devez l'activer avant que Mercurial reconnaisse la commande convertie. p> Si vous utilisez Tortoise HG ou FRUN, par exemple: p> ou éditer Mercurial.ini directement: p> aller dans le répertoire au-dessus de votre référentiel (dans mon exemple, mes repos sont HelloApp): P > Créer un fichier nommé FileMap.txt P> LI>
ajoutez une ligne avec le chemin complet du nom de fichier que vous souhaitez exclure. p>
Ouvrez une invite de commande, CD dans le même répertoire, contenant votre fichier FileMap.txt et exécutez le HG Convert P>
puis obtenez la dernière copie de travail: p>
cd HelloApp_clean
hg update
cd C:\projects
hg convert --filemap filemap.txt HelloApp HelloApp_clean
exclude HelloApp/sensitive.config
Dupe: Stackoverflow.com/Questtions/1029480/...
La réponse donnée là-bas n'est pas très utile. C'est techniquement correct dans un sens. Mais si vous êtes prêt à dire à toutes les personnes qui auraient pu cloné votre référentiel pour dépouiller une modification, vous pouvez supprimer la modification qui introduit le changement, puis utilisez quelque chose comme une greffe pour déplacer tous les changements après cela et leur donner Nouvelle validation des hachages.
La réponse de Martin Geisler est bien meilleure et est une autre méthode en plus de celle que j'ai suggérée.