Odzyskiwanie po nieudanym ponownym uruchomieniu

Używam git svn do uzyskania dobrej jakości git z autoryzowanym przez firmę serwerem svn. Właśnie miał rebase iść strasznie krzywo, a ja "m próbuje dowiedzieć się, że najlepszym sposobem na odzyskanieOdzyskiwanie po nieudanym ponownym uruchomieniu

Oto co się stało.

Na początek, miałem ten

---1 (master) 
    \--B--C--D--E (feature/fix-widgets)

Tak więc zrobiłem git checkout master, a następnie git svn rebase na master, aby usunąć te zatwierdzenia.Nie przewidywałem żadnych konfliktów między moją gałęzią funkcji a wzorcem, ponieważ zmiany były w zupełnie innym folderze. Więc w tym momencie myślę Mam to:
```
---1--2--3--4 (master) 
    \--B--C--D--E (feature/fix-widgets) 
```
Gdzie 1--2--3--4 są zobowiązuje wyciągnął z SVN.
Następnie wykonuję git checkout feature/fix-widgets, a następnie git rebase master. Natychmiast dochodzi do konfliktu i niektórych rzeczy, które się nie sumują, więc postanawiam odejść i przyjrzeć się uważniej. Robię git rebase --abort, mając nadzieję, że przywróci mnie to do miejsca, w którym znajdowałem się przed zbiorem.

zrobić git rebase --abort i pojawia się następujący komunikat

$ git rebase --abort 
    error: git checkout-index: unable to create file somedir/somefile.cs (Permission denied) 
    fatal: Could not reset index file to revision 'be44daa05be39f6dd0d602486a598b63b6bd2af7'.

Teraz nie jestem pewien, co zrobić. git status pokazuje, że jestem na feature/fix-widgets, ale mam całą masę zmienionych etapów oraz dużą liczbę nieśledzonych plików, które zostały wcześniej zatwierdzone. Byłbym w porządku, gdybym mógł odzyskać E.

Źródło

2011-01-11 notJim

Spotkałem się z tym samym problemem - zgaduję, że korzystasz z git na Windows, ten uroczy system operacyjny, który myślał, że udostępnianie zamków było dobrym pomysłem. Domyślam się, że powodem, dla którego dusił on plik somedir/somefile.cs, było to, że był gdzieś otwarty ... to było przyczyną mojego nieudanego rebase. Zamknięcie wszystkich otwartych programów, jakie mogłem znaleźć, zresetowanie zgodnie z wybraną odpowiedzią, a następnie ponowne przesłanie, działało bez problemu. –

+1 za dobrze napisane pytanie, które uratowało mnie przed płaczem. – Tinman

Trzeba spojrzeć na ORIG_HEAD

ORIG_HEAD jest poprzedni stan HEAD, ustawiony za pomocą poleceń, które mają potencjalnie niebezpiecznych zachowań, aby być łatwo je przywrócić.
Jest mniej przydatna teraz, że Git ma reflog: [email protected]{1} jest z grubsza odpowiednikiem ORIG_HEAD ([email protected]{1} jest zawsze ostatnia wartość HEAD, ORIG_HEAD jest ostatnia wartość HEAD przed niebezpiecznym eksploatacji)

Więc spróbuj tego git reset wrócić przed jakimkolwiek przebiciem:

git reset --hard ORIG_HEAD

Źródło

2011-01-11 17:55:10 VonC

Cóż, to było łatwe. Zrobiłem reset, a potem po prostu głupio próbowałem ponownie założyć bazę i zadziałało. * wzruszenie ramion * – notJim

@notJim: true, ale może być przydatne zachowanie 'ORIG_HEAD' podczas wykonywania tych poleceń. Może się przydać. – VonC

Odzyskiwanie po nieudanym ponownym uruchomieniu

Odpowiedz

Powiązane problemy