Dlaczego polecenie git-svn dcommit zostawia duplikaty commitów w moim repozytorium git? Czy mogę to powstrzymać?

Question

Mój typowy git-svn pracy jest:

git checkout -b story-xyz 
git commit -a -m "work" 
git commit -a -m "more work" 
git checkout master 
git svn fetch 
git merge remotes/trunk 
git checkout story-xyz 
git rebase master (sometimes with -i) 
git checkout master 
git merge story-xyz 

W tym momencie mam moje master i story-xyz gałęzie wskazując samo popełnienia, popełnia jeden lub więcej przed remotes/trunk. Wszystko od remotes/trunk jest w jednej historii liniowej.

last svn commit [remotes/trunk] <--- work <--- more work [master, story-xyz] 

I następnie uruchomić

git svn dcommit 

Spodziewałem się zobaczyć zobowiązuje między remotes/trunk i master stają wersjami Subversion i skończyć z jednym historii liniowej z remotes/trunk, master i story-xyz wszystko wskazuje na ostatni rewizja, tak jak:

last svn commit <--- work <--- more work [master, story-xyz, remotes/trunk] 

Moje wersje Subversion wchodzą w porządku, ale kończę na strukturze rozgałęzionej. Wspólnym katalogiem oddziału jest Subversion HEAD, zanim popełniłem. Obie gałęzie zawierają tę samą serię zatwierdzeń, w tym sensie, że zawierają te same różnice. Oddział story-xyz jest na czele jednej gałęzi, remotes/trunk i master na drugim:

last svn commit <--- work <--- more work [master, remotes/trunk] 
        | 
        \- work <--- more work [story-xyz] 

git popełnia, że ​​miałem przed uruchomieniem git svn dcommit się na niższych gałęzi (story-xyz), z moim git commit wiadomości, git nazwa użytkownika i adres e-mail oraz sygnatury czasowe git commit. Zatwierdzenia w górnej gałęzi są nowymi zatwierdzeniami git. Używają mojej nazwy użytkownika Subversion, znacznika czasu, kiedy uruchomiłem dcommit, a wiadomości zatwierdzenia mają dołączone do nich pole git-svn-id.

To wszystko jest w porządku i mogę dalej pracować. Problem polega na tym, że patrzę w gitk i widzę, co wygląda jak niezamknięta gałąź story-xyz. Trudno powiedzieć różnicę między gałęzią fabularną, którą połączyłem z powrotem w master, a tą, której nie mam. Najbardziej oczywistym sposobem na jej wykrycie są zduplikowane komunikaty o zatwierdzeniu. Mogłem usunąć gałąź story-xyz, ale wydaje mi się, że nie używam git poprawnie i straciłem część mojej historii.

Czy brakuje mi czegoś, co powstrzymałoby przed tym git-svn? Czy jest to tylko jeden ze sposobów, w jaki interakcja z Subversion osłabia siłę i wolność git?

Answer 1

Nie sądzę, że naprawdę czegoś brakuje. Być może jednak wykonujesz niepotrzebną pracę. W tym przypadku masz dwa wskaźniki do zatwierdzenia "więcej pracy", a ty prosisz git-svn, aby przesunął jeden z nich. Drugi wciąż pozostaje tam, gdzie jest.

Nie potrzebujesz oddziału master. Git-svn nie dba o to, jaką gałąź prowadzisz. IIRC, wykorzystuje pierwszy svn-remote, który może znaleźć wśród przodków bieżącego zatwierdzenia.

będę oferują kolejną wersję workflow:

git checkout -b story-xyz remotes/trunk 
git commit -a -m "work" 
git commit -a -m "more work" 
git svn fetch 
git rebase remotes/trunk (with -i, perhaps) 
git svn dcommit 

To powinno dać drzewo bez dodatkowego oddziału. Trzeba jednak uważać na szybkie łączenie w przód.