2012-07-06 14 views
19

Użyłem następującego polecenia, aby sklonować repozytorium svn w git i po jego wykonaniu widzę kilka fałszywych gałęzi.klon git-svn | fałszywe gałęzie

git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt --stdlayout ~/temp

git branch -a

*(no branch) 
    master 
    remotes/abc-1.3.x 
    remotes/[email protected] 
    remotes/[email protected] 
    remotes/branch_test_script 
    remotes/tags/modules-1.2 
    remotes/tags/[email protected] 
    remotes/tags/[email protected] 
    remotes/tags/release-1.1 
    remotes/tags/[email protected] 
    remotes/tags/[email protected] 
    remotes/trunk 

Rzeczywiste oddziałów utworzonych w SVN były abc, branch_test_script, moduły i uwolnienie. Czy ktoś może pomóc w zrozumieniu, co "[email protected]", "[email protected]" ... "[email protected]" itd.?

Jak możemy pozbyć się tych fałszywych gałęzi/co one oznaczają?

Dzięki,
GAYATHRI

+0

Naprawdę ciężko mi się dowiedzieć, skąd się wzięło to nazewnictwo, ale wygląda na to, że te gałęzie powstają z przywilejów SVN, które, jak się okazało, nie są już przywoływane przez gałąź lub znacznik svn, na którym zostały pierwotnie wykonane. Podobnie jak nieokreślone zatwierdzenia w Git, z wyjątkiem tego, że można odzyskać nazwę oddziału dla zatwierdzenia. – fork0

+0

@ fork0: Dzięki za odpowiedź. Ale nie rozumiem jasno, w jaki sposób nieuznane zatwierdzenia mogą być obecne w svn. W jaki sposób można utracić referencje? Czy możesz podzielić się swoimi przemyśleniami na ten temat? – crankparty

+0

Nie wiem. Może opiekun repozytorium SVN nigdy ich nie wyczyścił (lub SVN nie ma w ogóle zdolności?). Nie chciałem powiedzieć, że referencje zostały utracone, a raczej ktoś dopiero zaczął popełniać z wcześniejszego punktu w historii. – fork0

Odpowiedz

15

tl; dr:

git svn tworzy te "@" - oddziały jeśli oddział (lub tag) został stworzony do podkatalogu (lub do innego katalogu, który nie jest śledzony przez git-svn). Zawsze będzie też "zwykła" gałąź o tej samej nazwie, ale bez przyrostka "@". Odcinek "@" istnieje tylko jako punkt rozgałęzienia dla zwykłej gałęzi.


Uwaga: Przesłałem do tego łatkę; Zmieniona wersja tego objaśnienia jest teraz częścią oficjalnej strony git svn, jako nowa sekcja "OBSŁUGA ODDZIAŁÓW SVN" (od Git 1.8.1).


W Subversion, gałęzie i tagi są tylko kopie drzewa katalogów, więc jest to możliwe (choć zwykle zniechęca), aby utworzyć oddział z katalogu, który sam nie oddział (lub tułowia) jest. Na przykład, przez kopiowanie/trunk/foo do/branches/bar, zamiast do kopiowania/trunk ("gałąź podkatalogów", że tak powiem), lub przez kopiowanie katalogu, który leży poza strukturą trunk/tags/branches (która jest możliwe w SVN).

W git jednak gałąź jest zawsze dla całego repo, gałęzie podkatalogów nie istnieją. W związku z tym git svn używa obejścia. Jeśli wykryje gałąź, która została skopiowana z katalogu, który sam nie jest śledzony jako gałąź przez git-svn, utworzy nową historię. Na przykład, dla oddziału podkatalogu gdzie/trunk/foo jest kopiowany do/oddziały/baru w r1234, stworzy:

  • Nowa git commit dla każdej wersji SVN z r1233 z tyłu (pamiętać, że liczba jest ostatnia wersja przed utworzeniem oddziału). Drzewa tych zatwierdzeń będą zawierać tylko podkatalog, który został rozgałęziony. Tak więc dla każdej wersji od r1233 do tyłu, zwykle będą dwa zatwierdzenia git, jeden z całym drzewem (utworzonym, gdy git-svn przetworzył historię trunk), i nowymi.
  • Fałszywa gałąź o nazwie "bar @ 1233" (nazwa oddziału @ rewizja), która została dodana do zatwierdzenia utworzonego z r1233 powyżej.
  • Zatwierdzenie z r1234, zatwierdzenie, które utworzyło gałąź. To zatwierdzenie będzie miało gałąź powyżej jako jej (jedyny) przodek.
  • Oddział o nazwie "bar", który wskazuje na drugie zatwierdzenie.

W ten sposób, za podkatalogu pasku oddziału, masz dwa oddziały w git

  • bar @ 1233, która reprezentuje stan repozytorium że oddział został utworzony z
  • baru, który reprezentuje oddział

Nie jestem do końca pewien, dlaczego utworzono gałąź fikcyjną. Myślę, że robi się to, aby reprezentować informacje o rewizji, od której rozgałęziono oddział, i mieć pełną historię dla oddziału.


Należy zauważyć, że cały mechanizm można wyłączyć za pomocą flagi --no-follow-parent. W takim przypadku każdy oddział SVN wygeneruje gałąź git z tylko zatwierdzeniami z katalogu gałęzi SVN. Każda gałąź będzie niezwiązana z resztą historii i będzie miała własne zatwierdzenie root, odpowiadające pierwszemu zatwierdzeniu w oddziale.

3

miałem takie dziwne zwanych gałęzie zbyt kiedy sklonowane moje SVN repo do repo Git.

Po zapoznaniu oczekiwanych oddziałów (w przypadku modules-1.2, abc-1.3.x, branch_test_script i release-1.1) Zauważyłem, że @revisionnumber gałęzie są niczym innym niż dopuszcza w swoich oddziałach prefiksem.

Jeśli chcesz zrobić to ręcznie, otwartej gitk na oddział abc-1.3.x i sprawdzić, czy [email protected] i [email protected] pokazać się w historii tego oddziału. Jeśli tak, możesz usunąć odpowiednią gałąź.

Może to być trochę uciążliwe, jeśli masz wiele oddziałów lub wiele zatwierdzeń do przeglądania.

automatyczny sposób: zapytać git to zrobić dla Ciebie:

git branch -r --contains [email protected] 

będzie echo (lub przynajmniej powinien)

abc-1.3.x 
[email protected] 
[email protected] 

Oznacza to, że można bezpiecznie usunąć [email protected] ponieważ jest zawarta w abc-1.3.x:

git branch -r -d [email protected] 

Ze względu na liniową historię SVN, zawiera ona oczywiście również (nowsze) zatwierdzenie 541512.


Notatka:
Można zauważyć, że tagi SVN w rzeczywistości nie są konwertowane tagów Git i rodzimych gałęzi Git. Można to osiągnąć za pomocą svn2git, aby sklonować repozytorium SVN do repozytorium Git.

+0

Jak usunąć te gałęzie? Czy istnieje parametr, który można przekazać do git, aby zignorować takie zatwierdzenia i nie tworzyć rozgałęzień? – crankparty

+0

Jak napisałem: gałęzie można usunąć przy użyciu 'git branch -r -d '. Nie sądzę, że istnieje flaga do osiągnięcia, że ​​gałęzie nie są tworzone. – eckes

+1

'git-svn' może niepotrzebnie tworzyć owe" @ "gałęzie, ale jest ważny przypadek, w którym' abc @ 113346' to ** nie ** przodek 'abc'. Dzieje się tak, gdy gałąź jest usuwana w subwersji, a następnie tworzona ponownie przez kopiowanie z innego punktu. Również fakt, że 'abc @ 113346' jest przodkiem' abc' nie oznacza, że ​​tak się nie stało, może to oznaczać, że 'abc' został scalony z trunkem, usunięty (w jakiejś wersji wyższej niż 113346) i nowy jeden stworzony w swoim miejscu z bagażnika. –