Получение "ошибка: нет такой фиксации" при попытке восстановить удаленную ветку? - PullRequest
Новая
       16

Получение "ошибка: нет такой фиксации" при попытке восстановить удаленную ветку?

0 голосов
/ 29 июня 2018

Я уже зафиксировал файл в Gerrit (выдвинул его), но, думаю, я, к сожалению, локально удалил ту ветку, из которой я зафиксировал. Как это исправить? Пожалуйста, помогите.

Я пытался 

    git branch --contains 31436fd7200566967f85bfb1ee5425f9b599b908

но это показывает 

    error: no such commit 31436fd7200566967f85bfb1ee5425f9b599b908

Редактировать: Да, я установил git локально и работал над веткой локально.

Я получил коммит с сайта Gerrit, я зафиксировал.

Хорошо, два дня назад сначала возникла проблема, когда я попытался зафиксировать изменение, скажем А. Я попытался отправить его, используя «./logerrit submit master», но все, что я получил, было: 

    Counting objects: 32, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (32/32), done.
    Writing objects: 100% (32/32), 100.46 KiB | 0 bytes/s, done.
    Total 32 (delta 22), reused 0 (delta 0)
    remote: Resolving deltas: 100% (22/22)
    remote: Counting objects: 79789, done
    remote: Processing changes: refs: 1, done    
    To ssh://logerrit/core
    ! [remote rejected] HEAD -> refs/for/master (change 
    https://gerrit.libreoffice.org/54112 closed)
    error: failed to push some refs to 'ssh://logerrit/core'

Итак, в нем говорится, что изменение идентификатора одинаково для двух коммитов - патча, который я фиксирую, и патча, который я уже зафиксировал несколько дней назад и теперь объединен. Я пытался сделать все возможное, что упомянуто о переполнении стека или любых других блогах - я пытался изменить идентификатор, чтобы при следующем «git commit --amend» git автоматически менял идентификатор, он был бесполезен, как и я Получив ту же ошибку, я также попытался исправить конфликты, удалив строки <<<<<<<<<<< =========== и >>>>>>>>>> > но правильно ли я с этим? Это правильный способ решить это? Затем я попытался "git rebase master", а затем я получил сообщение об ошибке: 

    First, rewinding head to replay your work on top of it...
    Applying: smartart : test documents
    Using index info to reconstruct a base tree...
    M   sd/qa/unit/import-tests-smartart.cxx
    Falling back to patching base and 3-way merge...
    Auto-merging sd/qa/unit/import-tests-smartart.cxx
    CONFLICT (content): Merge conflict in sd/qa/unit/import-tests- 
    smartart.cxx
    error: Failed to merge in the changes.
    Patch failed at 0001 smartart : test documents
    The copy of the patch that failed is found in: .git/rebase- 
    apply/patch

    When you have resolved this problem, run "git rebase --continue".
    If you prefer to skip this patch, run "git rebase --skip" instead.
    To check out the original branch and stop rebasing, run "git rebase --abort".

Я попытался изменить ветку, а затем снова попытался переназначить изменения с помощью мастера, так как они уже были обновлены, но это было бесполезно. Затем я удалил дополнительные ветки, созданные «локально», и по ошибке мог удалить одну из веток, из которых я зафиксировал Gerrit.

Теперь мой вопрос:

  1. Могу ли я снова восстановить удаленную ветку в моей локальной системе? Возможно ли это?
  2. Как решить проблемы слияния или ошибку, которую вы увидели после перебазировки. У меня есть сильное сомнение, я могу что-то не так делать Пожалуйста, помогите и, пожалуйста, дайте мне знать, если я ничего не освещал.

И первый, и второй вопросы относятся к разным файлам / ветвям, но могут быть связаны друг с другом.

Ответы [ 4 ]

0 голосов
/ 11 июля 2018

При использовании Gerrit возможно, что коммит, который заканчивается в репозитории, имеет другой sha1, чем исходный коммит, который вы нажали. Это может произойти по нескольким причинам:

  • Изменение перебазируется пользователем (либо в пользовательском интерфейсе, либо кем-то, кто загружает его и отправляет перебазированный набор патчей), либо загружается новый набор патчей
  • Изменение будет перебазировано при отправке, если проект использует Rebase if Necessary стратегию отправки
  • В проекте используется стратегия Cherry Pick, и создается новый коммит для всех изменений при отправке.

Фактический коммит sha1 вы можете увидеть в пользовательском интерфейсе Gerrit. Точное местоположение зависит от того, какая версия Gerrit и какой пользовательский интерфейс (GWT или Polymer) используются.

0 голосов
/ 29 июня 2018

Забудьте о коммите 31436fd7200566967f85bfb1ee5425f9b599b908. Если вы действительно слили свой коммит в Gerrit, он находится в удаленной ветке. Для создания и извлечения локальной ветви из удаленной ветви выполните: 

git checkout -b local-branch remotebranch

Ex: 

git checkout -b my-feature origin/release1.0
0 голосов
/ 09 июля 2018

Я не знаю, будет ли это соответствовать вашим потребностям, но вы должны иметь возможность свежим образом извлекать текущую главную ветку с пульта, а затем применить то же изменение, которое вы пытаетесь получить. Если у вас нет каких-либо дополнительных изменений, о которых вы не упомянули, это даст вам все необходимое, чтобы воспроизвести изменение и двигаться дальше.

Эти шаги будут уничтожить вашего локального мастера и восстановить его с пульта: 

# delete local master
git branch -D master
# fetch latest branches from remote
git fetch
# checkout master fresh from remote
git checkout master

Затем вручную скопируйте содержимое с ресурса gitweb:

https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=31436fd7200566967f85bfb1ee5425f9b599b908

... в единственный файл, который изменился в этом коммите, sd/qa/unit/import-tests-smartart.cxx.

Результатом является текущая основная ветвь с примененным искомым изменением. Далее я предполагаю, что вы либо создадите новую ветку с git checkout -b <new-branch>, либо останетесь в master, а затем передадите изменения. Наконец, вы можете нажать как нужно.

0 голосов
/ 29 июня 2018

Поскольку вы уверены, что коммит существует на удаленном компьютере, он должен найти его: 

git branch -r --contains 31436fd7200566967f85bfb1ee5425f9b599b908

Как только вы узнаете, в какой удаленной ветке находится нужный вам коммит, давайте назовем его <branch>, тогда вы сможете локально воссоздать эту же ветку с помощью: 

# delete same-named local branch (if it exists)
git branch -D <branch>
# fetch latest branches from remote
git fetch
# checkout branch from remote
git checkout <branch>

Aknowledgements:

...