2014-09-19 32 views
6

Potrzebuję zautomatyzować interaktywny rebase lub zastąp go innymi poleceniami. Po prostu pozwól mi wyjaśnić moją obecną sytuację:git: Jak zautomatyzować interaktywny rebase/zastąp go odpowiednimi poleceniami git.

W przejściu svn-> git muszę ponownie utworzyć nowo utworzone repozytorium git, aby naprawić "odcięcia historii" wykonane podczas SVN. Oto mój ręczny przepływ pracy, aby rozwiązać problem.

branchNEW: containing history from SOMEDAY until now 
branchOLD: containing history from past to SOMEDAY 

EDIT lub ASCII:

branchNEW:  Y - Z 
branchOLD: W - X 

Obie gałęzie nie mają wspólnych zobowiązuje.

Podstawową ideą jest teraz tylko odnowienie gałęziNEW na branchOLD. Niestety nastąpiła korekta SOMEDAY: Niektóre pliki zostały przeniesione do innego katalogu. Rezultatem rebase jest teraz, że każdy przeniesiony plik istnieje w obu miejscach.

EDIT

some file exist in X 
the (nearly) same files also exist in Y, just on another path 

branchNEW: W - X - Y - Z 
(after rebase) 

Po rebase, HEAD zawiera teraz pliki z X i Y. Próbowałem też dodać nowy zobowiązać się do branchOLD który usuwa stare pliki. Po zbiorze SVN-HEAD i git-HEAD są identyczne binarnie, ale "git log - follow" nie działa.

teraz do głównego problemu: Jestem w stanie rozwiązać ten problem za pomocą drugiego, interaktywne rebase:

git rebase -i SHA 

SHA jest sha-id starego korzenia popełnić w branchNEW. Teraz w edytorze muszę zmienić "pick", aby "edytować" dla najwyższego zatwierdzenia. Po wyjściu z edytora i teraz trzeba usunąć niewłaściwych plików

git rm -f fileA fileB 
git commit --amend 
git rebase --continue 

Po tym HEAD git jest binarny identyczne szefa SVN a ponadto git ma pełną historię, a także „Log git --follow” dzieła dla przeniesionych plików.

Ponieważ ten krok jest tylko niewielką częścią ogromnego przejścia VCS w przyszłości, muszę napisać cały proces. Ale jak zautomatyzować powyższe kroki?

(wiem, że Shas nie pozostanie taka sama, ale jestem w stanie uzyskać wymaganego SHA z SVN-ID, który jest wbudowany w każdy popełnienia wiadomości)

+0

Nie jestem pewien, ale chyba 'git filter-branch' mógłby pomóc. – Jubobs

Odpowiedz

3

Znalazłem możliwe rozwiązanie:

git rebase --interactive wysyła "listę przydziałów rebase" (listę, w której możesz wybrać, przechować, edytować, ...) do edytora. Jaki rodzaj edytora można skonfigurować. Rozwiązaniem jest więc skonfigurowanie alternatywnego "edytora" tylko dla tego interaktywnego rebase.Można to zrobić ustawiając zmienną środowiskową GIT_SEQUENCE_EDITOR:

GIT_SEQUENCE_EDITOR="command" git rebase -i SHA 

polecenie może być skrypt powłoki lub po prostu prosty sed:

GIT_SEQUENCE_EDITOR="sed -i 's/^pick ce5efdb /edit ce5efdb /;/^pick ce6efdb /d'" git rebase -i SHA 

Ważne: „lista rebase zobowiązuje” jest przekazywana jako plik do polecenia . Polecenie musi więc zaakceptować nazwę pliku jako parametr i zapisać wynik w tym samym pliku. "sed -i" właśnie to robi.

+0

Muszę zautomatyzować zgniatanie kilku historycznych zatwierdzeń w repozytorium, aby utworzyć skrypt, który wykona wszystkie niezbędne operacje związane z migracją z svn jako dowód koncepcji, którą inni członkowie projektu mogą wykorzystać w pełni odtwarzalny sposób. sprawdź, czy migracja jest prawidłowa. To jest po prostu idealne. – Irfy

0

expect może ci też pomóc. Choć nie jest to całkiem co trzeba zrobić, powinieneś być w stanie korzystać z czegoś podobnego do automatyzacji procesu:

#!/usr/bin/env expect 
spawn git rebase -i HEAD~2 

# down, delete word, insert 's' (for squash), Escape, save and quit 
send "jdwis \033:wq\r" 

expect "# This is a" 

# down 4, delete 3 lines, save and quit 
send "4j3d:wq\r" 

interact