git notatek po BFG?

Question

Przeprowadziłem migrację z SVN do git i miałem notatkę w każdym zatwierdzeniu git odnoszącym się do numeru wersji SVN. Po imporcie repo użyłem narzędzia do usuwania repozytoriów BFG, aby wyczyścić historię git z plików binarnych i innych śmieci. Niestety teraz nie widzę notatek, gdy wpisuję git log. Przypuszczam, że BFG zapomina zaktualizować referencje o zatwierdzeniach do notatek. BFG pozostawia * Sprawozdanie .txt z mapowaniem stary identyfikator obiektu do nowego obiektu id w następującym formacie:

0001b24011381e8885683cd1119ba4cb077fa64b c81149b1b52b9e1e1767d6141f292891d715edb5 
00024eecdc31f2f6e67018f7d6f00e7c1ad03f1f 326ee3b508e3dd2934ec1f50069195f86ea1a1c7 
00028e04dcc2d59bd835b447bd3a207ae481696c 3d18e9b9d3336e59d62093200b81603ffefcc747 

można zaproponować jakiś skrypt, aby szybko naprawić notatki biorąc pod uwagę powyższe mapowania?

PS: Jestem prawie pewien, że problem jest spowodowany przez nie zaktualizowanych literatury, bo gdy wpisuję git notes na drugim miejscu widzę pozycje literatury, które są uważane za stary w BFG repot object-id-map.old-new.txt

Answer 1

napisałem poniższy skrypt bash, aby przenieść swoje notatki ze starych obiektów.Rozwiązanie jest powolne w pojedynczym wątku, nie jest pewne, czy można bezpiecznie uruchamiać równolegle kilka poleceń git notes.

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 

Answer 2

Nic zbudowany w tym celu ; będziesz musiał napisać skrypt lub program samodzielnie. Z drugiej strony, BFG zostawił ci plik mapy: jest o wiele ładniejszy niż git filter-branch, który go wyrzuca, dzięki czemu informacje potrzebne do aktualizacji twoich notatek zniknęły.

Podstawowa wdrożenie w notach że refs/notes/commits (lub cokolwiek ustawić dla core.notesRef) wskazuje na zwykłym popełnienia, który można przynajmniej w teorii git checkout (prawdopodobnie w tymczasowym drzewie pracy skonfigurowano specjalnie do tego celu). To drzewo zawiera pliki, których nazwy zawierają tylko nieznacznie zmodyfikowane komentarze. Na przykład, jeżeli:

0001b24011381e8885683cd1119ba4cb077fa64b c81149b1b52b9e1e1767d6141f292891d715edb5 

jest wpis mapping, z 0001b24011381e8885683cd1119ba4cb077fa64b będąc starym popełnienia, a jeśli 0001b24011381e8885683cd1119ba4cb077fa64b ma wpisu notatki, tam będzie plik, którego nazwajest 0001b24011381e8885683cd1119ba4cb077fa64b -tylko, może to być 00/01b2... lub 00/01/b2....

Głębokość zagnieżdżania wszystkich dodanych podkatalogów jest zarządzana dynamicznie według kodu notatek, przy czym ogólna zasada brzmi: "dodaj tyle drzew, ile potrzeba, aby znaleźć, czy jest notatka, szybko, ale nie tak wiele drzew co zajmuje dużo miejsca w repozytorium, gdy jest bardzo mało nut zaczynających się od 0001b2.... To rozchodzenie się nie ma kluczowego znaczenia dla twoich celów, chociaż możesz chcieć go utrzymywać z tej samej przyczyny prędkości ..

Twoja praca będzie znajdował każdy plik w tym drzewie pod nazwą o starej nazwie i przenosił (lub kopiował) do nowej nazwy nowej pasującej do nowej komendy t ID. Ponieważ nowa nazwa w tym przypadku to c81149b1b52b9e1e1767d6141f292891d715edb5, należy zmienić nazwę pliku na c8/1149b1b52b9e1e1767d6141f292891d715edb5 lub c8/11/49b1b52b9e1e1767d6141f292891d715edb5 itd. Po zmianie nazwy wszystkich plików (za pomocą indeksu: użyj git mv lub git rm --cached i git add w razie potrzeby), możesz je włączyć w zwykły obiekt commit z git write-tree, a następnie git commit-tree. Ustaw nadrzędną nowego zatwierdzenia jako istniejący zatwierdzenie refs/notes/commits i użyj git update-ref, aby zaktualizować refs/notes/commits, aby wskazać na nowy zatwierdzenie, a twoje notatki powinny pojawić się ponownie, po filtrowaniu.

(Gdy masz taką pracę sprawa, że ​​byłoby miło, aby dołączyć go z git filter-branch i/lub samego BFG).