Dlaczego "git rebase" pozostawia przeciwne zestawy modyfikacji na scenie i kopii roboczej?

Question

Używam git-svn jako klienta svn. Od czasu do czasu napotykam następujący problem.

1. zacznę z kilku zatwierdzeń w moim lokalnym oddziale git, na pustej scenie i czystej kopii roboczej.

2. wpisaniu „git svn rebase” w wierszu poleceń systemu Windows do pobrania modyfikacji zespołu i umieścić mój popełnić po nich, aby zachować historię liniowej (to jest wymagane do korzystania z git-svn)

3. Wszystko idzie dobrze , zawartość zespołu jest pobierana, a moje zatwierdzenia są ponownie tworzone po tym czasie, ale ...

   Kończę modyfikacjami kopii roboczej i zmodyfikowanymi plikami na etapie, a modyfikacje kopii roboczej są dokładnie odwrotne modyfikacji na tym etapie.

zwykle obejść tylko unstaging wszystko, co jest w fazie, która przywraca modyfikacje w kopii roboczej, co jest w porządku, ale naprawdę chciałbym, aby zrozumieć, co się tutaj dzieje.

Pytanie: Czy to błąd, czy też jest to coś, czego nie rozumiem przez git rebase?

Uwaga: Wystąpił problem podczas używania "git svn fetch" i "git rebase" później.

Uwaga: Używam git w oknach z dużym repozytorium svn (ponad 10000 plików, ponad 150000 wersji), a także używam rozszerzeń git. Edytuj: Używam go tylko eksploruj repozytorium i zatwierdzaj. Robię cokolwiek innego z wiersza poleceń systemu Windows.

Edytuj: Zgodnie z żądaniem jednego z komentarzy, oto dwa zrzuty ekranu, które pomagają zrozumieć problem. Pierwsza to treść kopii roboczej, druga to zawartość sceny. Można łatwo zobaczyć oba są dokładnie oposite:

Working Copy:

Stage (powraca pracy modyfikacje kopiowania, bardzo optyczny: ten sam obraz, czerwony i zielony są zamienione):

Edycja: Po prostu odtworzyłem problem w bardzo prostym przypadku: Mój commit modyfikuje tylko jeden plik, bardzo niewiele nowych commitów zostało pobranych podczas "git svn rebase" i żaden z nich nie wpłynął na zmodyfikowany plik. Sprawdziłem z "gitk - all". Mówi dokładnie to samo, co rozszerzenia git i "git status" Tutaj jest wyjście gitk. Widzimy od dołu do góry:

• Ostatnie 3 wiersze to 3 zatwierdzenia, które zostały pobrane przy ponownym tworzeniu. Żadne z nich nie dotyka mojego pliku.
• Trzecia linia od góry pokazuje moje zatwierdzenie po rebase: wszystko dobrze, dodaje to, co ma dodawać i usuwa to, co ma usunąć.
• The 2nd linia pokazuje zawartość indeksu: zawiera modyfikacje, które cofnąć mój popełnić
• The 1st linia pokazuje zawartość kopii roboczej: zawiera te same modyfikacje, które mój popełniają robi, IE powraca modyfikacja w indeksie.

Edit: Oto treść mojego .git reż po "git svn rebase", gdzie wystąpił problem:

17/02/2012 04:57     0 ArmuazEm5Z 
05/04/2012 02:28     0 BeMzRLwWcu 
06/11/2012 14:37    90 COMMIT_EDITMSG 
01/11/2012 15:42    628 config 
15/02/2012 04:21    73 description 
16/02/2012 13:22     0 fuMhUevkYu 
05/11/2012 15:53   1 703 279 gitk.cache 
05/07/2012 03:49     0 gJfUbdRuG9 
06/11/2012 14:42    23 HEAD 
11/07/2012 03:14 <DIR>   hooks 
21/02/2012 03:22     0 II5HPacSJd 
06/11/2012 14:42   5 439 960 index 
15/10/2012 13:18 <DIR>   info 
16/02/2012 08:16     0 jerS1GtBYS 
17/02/2012 04:57     0 Kg64sq9pzS 
15/02/2012 23:36     0 lbe0yALJYy 
15/10/2012 13:17 <DIR>   logs 
19/10/2012 16:58 <DIR>   objects 
06/11/2012 14:42    41 ORIG_HEAD 
25/10/2012 11:02    2 795 packed-refs 
05/07/2012 03:49     0 PpxYa5z0Hc 
02/11/2012 10:00 <DIR>   refs 
15/02/2012 23:36     0 sm6ociDGGF 
06/11/2012 14:42 <DIR>   svn 
21/02/2012 03:22     0 vEqtL0Yiqd 
05/04/2012 02:28     0 VFwn3laTEV 
16/02/2012 13:22     0 XYoiLqY5BM 
16/02/2012 08:16     0 z9vL8lRT7t 
       22 File(s)  7 146 889 bytes 
       6 Dir(s) 54 105 219 072 bytes free 

Edit: Jeśli jesteś zainteresowany w śledzeniu tego problemu zgłosiłem błąd na liście mailingowej git@vger.kernel.org z "[git-svn] [zgłoszenie błędu] Indeks w dziwnym stanie po git svn rebase" w temacie.

Answer 1

Wygląda na to, że jest to błąd. Jeśli twój katalog roboczy i indeks są czyste przed ponownym uruchomieniem, powinny być czyste po zmianie nazwy; lub powinieneś uzyskać konflikt scalania i możliwość jego wyczyszczenia i kontynuowania reorganizacji.

Wygląda na to, że z jakiegoś powodu twój indeks jest nieaktualny po zastosowaniu lokalnych modyfikacji.

Zasadniczo istnieją trzy główne widoki bieżącego stanu repozytorium. Istnieje zatwierdzenie HEAD, które jest stanem repozytorium od ostatniego zatwierdzenia i jakie będzie twoje następne zatwierdzenie. To jest poprawnie aktualizowane podczas zmiany bazy; HEAD jest teraz lokalnym zatwierdzeniem, opartym na repozytorium wyższego poziomu.

Istnieje indeks, który powinien zawierać widok stanu następnego zatwierdzenia. Wydaje się, że jest to problem. Po pomyślnym usunięciu z czystego drzewa indeks powinien wyglądać tak samo jak repozytorium HEAD, ale wygląda na to, że otrzymuje stały widok tego, co zawiera repozytorium. Wygląda na to, że nie jest aktualizowany po zastosowaniu lokalnych poprawek w repozytorium upstream.

I jest twoja kopia robocza; rzeczywiste pliki na dysku. Z jakiegoś powodu, podczas wykonywania rebase, zatwierdzenie head jest aktualizowane poprawnie, a drzewo robocze jest aktualizowane poprawnie (lub jest pozostawione w spokoju), ale indeks pozostaje w stanie, który odwołuje się do zatwierdzenia pochodzenia, jesteś na zmianę. Oznacza to, że jeśli porównasz indeks z zatwierdzeniem rebased, wygląda na to, że cofnąłeś swoje zmiany, a jeśli porównasz kopię roboczą z indeksem, oznacza to, że dodałeś je ponownie.

Kilka rzeczy do sprawdzenia:

1. Może pokażesz nam zawartość katalogu .git po takiej problematycznej rebase? Pomocna byłaby tylko lista plików na najwyższym poziomie .git. W rzeczywistości pełna lista, w tym nazwy plików, daty modyfikacji i uprawnienia, może dać trochę więcej informacji.
2. Czy korzystasz z tego przez dowolny sieciowy system plików lub cokolwiek innego dziwnego? Sieciowe systemy plików czasami mają problemy z pozostawionymi plikami; Zastanawiam się, czy to się z tobą dzieje.
3. Jakiej wersji Git używasz?