2016-11-21 1 views
5

J'ai migré de SVN vers git et j'avais une note dans chaque commit git référençant au numéro de révision SVN. Après l'importation repo j'ai utilisé BFG repo cleaner pour nettoyer l'historique git à partir de fichiers binaires et d'autres déchets. Malheureusement maintenant je ne vois pas de notes quand je tape git log. Je suppose que BFG oublie de mettre à jour les références sur les validations pour les notes. BFG laisse un rapport * txt avec la cartographie ancienne id objet nouvel ID d'objet dans le format suivant:notes git après BFG?

0001b24011381e8885683cd1119ba4cb077fa64b c81149b1b52b9e1e1767d6141f292891d715edb5 
00024eecdc31f2f6e67018f7d6f00e7c1ad03f1f 326ee3b508e3dd2934ec1f50069195f86ea1a1c7 
00028e04dcc2d59bd835b447bd3a207ae481696c 3d18e9b9d3336e59d62093200b81603ffefcc747 

Pouvez-vous suggérer un script pour corriger rapidement les notes ci-dessus étant donné la cartographie?

PS: Je suis presque sûr que le problème est dû à ne pas refs mis à jour, parce que quand je tape git notes à la deuxième place, je peux voir refs qui sont considérés comme vieux dans BFG rempoter object-id-map.old-new.txt

+0

BFG n'a pas beaucoup d'options, car son but est d'être simple. Si vous voulez un référentiel propre, vous ne devriez peut-être créer qu'une seule validation de la dernière révision. Si votre projet n'a pas une grande histoire ou si vous êtes le seul à y travailler. Ce ne sera pas un problème. [this] (http://stackoverflow.com/questions/1186535/how-to-modify-a-specified-commit-in-git) post pourrait vous aider, si vous voulez changer votre commit. – Stargateur

+0

@Stargateur c'est un énorme vieux repo. J'ai utilisé 'java -jar bfg-1.12.14.jar -D" *. {Jar, guerre, zip, dll, pdb} "--delete-dossiers" Printemps "' – Derp

Répondre

1

j'ai écrit le script bash qui suit pour transférer mes notes à partir de vieux objets.La solution est lente dans un thread unique, pas sûr si il est sûr d'exécuter plusieurs commandes git notes en parallèle. "SVN to git" ✅, Quelle est la commande que vous utilisez avec BFG?

while read string; do 
    hashesArray=($string) 
    git notes copy ${hashesArray[0]} ${hashesArray[1]} 
    git notes remove --ignore-missing ${hashesArray[0]} 
done <object-id-map.old-new.txt 
0

Il n'y a rien construit pour faire ; vous devrez écrire le script ou le programme vous-même. Sur le bon côté, BFG vous a laissé le fichier map: c'est beaucoup plus beau que git filter-branch, qui le jette, de sorte que les informations dont vous avez besoin pour mettre à jour vos notes ont disparu.

La mise en œuvre sous-jacente dans les notes que refs/notes/commits (ou tout ce que vous définissez pour core.notesRef) des points à un commettras ordinaire, vous pouvez au moins en théorie git checkout (probablement dans un arbre de travail temporaire vous mis en place spécialement à cet effet). Cet arbre contient des fichiers dont les noms sont uniquement des commits annotés, légèrement modifiés. Par exemple, si:

0001b24011381e8885683cd1119ba4cb077fa64b c81149b1b52b9e1e1767d6141f292891d715edb5 

est une entrée de mappage, avec 0001b24011381e8885683cd1119ba4cb077fa64b étant un vieux commettras, et si 0001b24011381e8885683cd1119ba4cb077fa64b a une entrée de notes, il y aura un fichier dont nom est 0001b24011381e8885683cd1119ba4cb077fa64b -Seulement, il pourrait être 00/01b2... ou 00/01/b2....

La profondeur d'imbrication de tous ces sous-répertoires ajoutés est géré dynamiquement par le code de notes, l'idée générale étant « ajouter autant d'arbres que nécessaire pour faire trouver s'il y a une note, rapide, mais pas tant d'arbres pour prendre beaucoup de place dans le référentiel quand il y a très peu de notes commençant par 0001b2... Ce fan-out n'est pas crucial pour vos besoins bien que vous souhaitiez le conserver pour les mêmes raisons de vitesse. sera de trouver chaque fichier dans cet arbre sous son ancien nom, et de le déplacer (ou de le copier) vers un nouveau nom qui correspond à la nouvelle commi t ID. Comme le nouveau nom dans ce cas serait c81149b1b52b9e1e1767d6141f292891d715edb5, vous renommez le fichier en c8/1149b1b52b9e1e1767d6141f292891d715edb5, ou c8/11/49b1b52b9e1e1767d6141f292891d715edb5, etc. Une fois que vous avez renommé tous les fichiers (via l'index: utilisez git mv ou git rm --cached et git add au besoin), vous pouvez les activer dans un objet de validation régulière avec git write-tree suivi de git commit-tree. Faites en sorte que le parent de la nouvelle validation soit le commit refs/notes/commits existant et utilisez git update-ref pour mettre à jour refs/notes/commits pour pointer vers la validation , et vos notes devraient réapparaître, après le filtrage.

(Une fois que vous avez un tel travail de chose, ce serait bien de le rejoindre avec git filter-branch et/ou BFG lui-même.)

+0

Merci, mais il semble trop compliqué, j'ai écrit script simple qui utilise 'git notes copy' – Derp

+0

' git notes copy' fait ce qui précède (bien ... comme une * copie * plutôt qu'un mouvement), mais une note à la fois (d'où la lenteur). Probablement bien pour votre cas. – torek