Восстановление после неудачной перебазировки

Я использую git svn, чтобы получить некоторые преимущества git с сервером svn, уполномоченным компанией. У меня только что произошла ужасная перебазировка, и я пытаюсь найти лучший способ восстановления.

Вот что произошло:

  1. Для начала у меня было это

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

  2. Затем я сделал git checkout master, а затем git svn rebase на мастере, чтобы вывести эти коммиты. Я не ожидал каких-либо конфликтов между моей функциональной веткой и мастером, потому что изменения были в совершенно другой папке. Итак, на данный момент, я думаю, что у меня есть это:

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

    Где 1--2--3--4 — это коммиты, полученные из svn.

  3. Затем я делаю git checkout feature/fix-widgets, а затем git rebase master. Сразу же возникает конфликт и некоторые вещи, которые не складываются, поэтому я решаю улизнуть и посмотреть на вещи более внимательно. Я делаю git rebase --abort, надеясь, что это вернет меня туда, где я был до перебазирования.

  4. Я делаю git rebase --abort и получаю следующее сообщение

    $ 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'.

  5. Теперь я не уверен, что делать. git status показывает, что я на feature/fix-widgets, но у меня целая куча поставленных изменений, и большое количество неотслеживаемых файлов, которые ранее были зафиксированы. Все было бы хорошо, если бы я мог вернуться E.


git git-svn rebase
person davidtbernal    schedule 11.01.2011    source источник
comment
Я столкнулся с той же самой проблемой сегодня - я предполагаю, что вы использовали git в Windows, эту прекрасную операционную систему, которая думала, что совместное использование блокировок было хорошей идеей. Я предполагаю, что причина, по которой он задохнулся на somedir/somefile.cs, заключалась в том, что он был где-то открыт... это было причиной моей неудачной перебазировки. Закрытие всех открытых программ, которые я смог найти, сброс в соответствии с выбранным ответом, а затем перебазирование, сработало без проблем.   -  person Paul d'Aoust    schedule 20.08.2012
comment
+1 за хорошо написанный вопрос, который спас меня от слез.   -  person Tinman    schedule 27.06.2013

Ответы (1)


arrow_upward
31
arrow_downward

Вам следует взглянуть на ORIG_HEAD

ORIG_HEAD — это предыдущее состояние HEAD, устанавливаемое командами, которые могут иметь опасное поведение, чтобы их можно было легко отменить.
Теперь, когда в Git есть reflog, это менее полезно: HEAD@{1} примерно эквивалентно ORIG_HEAD (HEAD@{1} всегда является последним значением HEAD , ORIG_HEAD — последнее значение HEAD перед опасной операцией)

Итак, попробуйте этот git reset, чтобы вернуться к нему перед любой перебазировкой:

git reset --hard ORIG_HEAD
person VonC    schedule 11.01.2011
comment
Что ж, это было легко. Сделал сброс, а потом просто тупо попробовал еще раз перебазировать, и все заработало. пожал плечами - person davidtbernal; 11.01.2011
comment
@notJim: правда, но может быть полезно помнить ORIG_HEAD при выполнении этих команд. Это может пригодиться. - person VonC; 11.01.2011