Après avoir réécrit l'historique des repo Git, l'ancien historique des commit est toujours visible

Question

J'ai utilisé efficiently rewriting (rebase -i) a lot of history with git pour remplacer le texte du fichier (Copyright <author> à Copyright <company>) pour l'intégralité de l'historique des commit d'un dépôt Git. Cela fonctionne, mais le ancien l'historique de validation est encore visible.

Dans la capture d'écran ci-dessous, le «nouvel» historique de la branche bleue vient après l'historique «ancien» indésirable de la branche violette. Comment puis-je me débarrasser de la «vieille» histoire? (Pourquoi il n'a pas « fusion » dans une histoire continue me bat!

Answer 1

Alors que l'interface graphique est SourceTree, par Atlassian. Et c'était correct. Le problème était que j'avais d'autres branches et tags référençant la "vieille histoire". Alors naturellement, ça colle!

raisonnent en termes de Retour vers le futur :)

Ainsi, « vous ne pouvez pas réécrire l'histoire » est en partie correcte, cela dépend de votre point de vue.

Doc Brown: Évidemment, le continuum temporel a été interrompu, créant une nouvelle séquence d'événements temporels résultant de cette réalité alternative.

Marty: Anglais, Doc!

Doc Brown: Ici. Ici, laissez-moi démontrer. Disons que cette ligne représente le temps. [dessine la ligne droite et pointe vers les lieux] Voici le présent 1985, le futur et le passé. Évidemment, quelque part dans le passé, la chronologie s'est inclinée vers cette tangente (branche) [trace une nouvelle ligne et écrit 1985A] créant une alternative 1985 (maître). Alterner à vous, moi et Einstein, mais la réalité pour tout le monde. Reconnaître cela? [montre Blast from the Past sac (tag)] C'est le sac le livre de sport est entré; Je sais parce que le reçu (tag) était encore à l'intérieur. Je les ai trouvés dans la machine à remonter le temps ... avec ça! (plus de balises)

Yay! Git est BTTF! Moralité: Supprimer les références et il cessera d'exister!

Answer 2

Vous ne pouvez pas réécrire l'histoire git. Ce n'est pas une chose d'autorité, personne ne refuse d'appliquer, il est quelque chose Un commit est un nom unique pour ce commit spécifique.Tout commit différent, en raison de n'importe quel changement dans son contenu, son histoire ou sa description, a un ID différent. est juste une balise que git utilise comme un parent implicite et qui se met à jour quand vous l'ajoutez git checkout) et fait maintenant référence à la nouvelle histoire que vous avez faite avec rebase (edit: err, plus probablement avec filter-branch ici). trunk 'tag fait toujours référence à l'historique original Si vous voulez oublier svn/trunk dans yo votre repo, git branch -d svn/trunk.

Answer 3

Je vous recommande d'utiliser le BFG Repo-Cleaner, une alternative plus simple et plus rapide à git-filter-branch spécialement conçue pour réécrire des fichiers de l'historique Git. Une façon de vous faciliter la vie est de traiter par défaut toutes les références (tous les tags, branches, etc) mais aussi 10 - 50x plus rapidement.

Vous devez suivre attentivement ces étapes ici: http://rtyley.github.com/bfg-repo-cleaner/#usage - mais le bit core est la suivante: télécharger le BFG's jar (nécessite Java 6 ou supérieur) et exécutez la commande suivante:

$ java -jar bfg.jar --replace-text replacements.txt my-repo.git 

Le fichier replacements.txt doit contenir tous les substitutions que vous voulez faire, dans un format comme celui-ci (une entrée par ligne - note les commentaires ne doivent pas être inclus):

pa$$word # Replace literal string 'pa$$word' - with '***REMOVED***' by default 
Copyright Volte==>Copyright MegaCorp  # Replace, specifiying replacement text 
regex:Copyright \w+==>Copyright MegaCorp    # Replace, using a regex 
regex:Copyright (\d{4}) \w+==>Copyright $1 MegaCorp  # Replace with reference 

Votre histoire entière du référentiel seront scannés, et une fi non binaire les fichiers (de taille inférieure à 1 Mo) seront remplacés: toute chaîne correspondante (qui n'est pas dans votre dernière validation) sera remplacée.