git p4 rebase пытается повторно применить прошлые коммиты

Question

У меня проблема с git p4 rebase, и я не знаю, как начать диагностировать проблему, тем более, в чем проблема.

Итак, у меня есть git-репо, клонированное из рабочей области Perforce с помощью git-p4, и оно используется в качестве удаленного репо, чтобы служить мостом, так что команда может использовать git против одного удаленного репо, а затем периодически я могу отправить изменения репо в рабочее пространство.

И обычно рабочий процесс заключается в том, что человек находится в основной ветке, вносит изменения, git -a commitс ними, git pullСнова тогда git pushПримените их к удаленному репо, или они сделают ветвь, а затем объединят эту ветвь обратно, когда они закончат, и затем передадут основную ветвь на удаленную. Они могут время от времени поднимать ветку, если они занимают больше суток.

Когда я возвращаю вещи, чтобы выполнить, я запускаю следующие команды в удаленном репо

git checkout -f
git clean -f
git p4 rebase --import-labels
git p4 submit -M --export-labels
git checkout -f
git clean -f

Удаленное репо не пустое, поэтому я запускаю проверку и очищаю до и после

В основном время от времени, после того, как изменения были перенесены обратно, когда я делаю git p4 rebase, я получаю следующую ошибку

Performing incremental import into refs/remotes/p4/master git branch
Depot paths: //depot/sub/folder/
No changes to import!
Rebasing the current branch onto remotes/p4/master
First, rewinding head to replay your work on top of it...
Applying: A commit that has already been made previously
Applying: A second commit that has already been made in a previous commit
Using index info to reconstruct a base tree...
<stdin>:15: space before tab in indent.
                            a line of text
<stdin>:24: space before tab in indent.
                another line of text
<stdin>:25: space before tab in indent.
                a third line of text
<stdin>:33: trailing whitespace.
        a forth line of text
<stdin>:71: trailing whitespace.

warning: squelched 1 whitespace error
warning: 6 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging file from second
CONFLICT (content): Merge conflict in a/file/in/the/second/pre-existing/commit/file.php
Auto-merging a/file/in/the/second/pre-existing/commit/file.php
Failed to merge in the changes.
Patch failed at 0002 A second commit that has already been made in a previous commit

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

Traceback (most recent call last):
  File "/usr/lib/git-core/git-p4", line 3373, in <module>
    main()
  File "/usr/lib/git-core/git-p4", line 3367, in main
    if not cmd.run(args):
  File "/usr/lib/git-core/git-p4", line 3150, in run
    return self.rebase()
  File "/usr/lib/git-core/git-p4", line 3167, in rebase
    system("git rebase %s" % upstream)
  File "/usr/lib/git-core/git-p4", line 183, in system
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'git rebase remotes/p4/master' returned non-zero exit status 1

Итак, у меня есть ряд вопросов, здесь, когда он делает git rebase, как часть git p4 rebase, он повторно применяет ряд коммитов, которые уже были применены к удаленному репо и которые были перенесены обратно в рабочую область из предыдущего git p4 rebase, Откуда взялись дублирующие коммиты? Почему он все еще пытается воспроизвести их через репо?

Когда я проверяю файл в рабочей копии хранилища, он совпадает с рабочим пространством, потому что я не внес никаких изменений, так как последний git p4 rebase, В следствии git rebase --continue на самом деле ничего не делает.

Единственное решение - запустить git rebase --skip но когда я это делаю, то же сообщение появляется при запуске git p4 rebase в следующий раз, и я должен повторить git rebase --skip каждый раз. Это бесит.

И иногда я не совсем уверен, каким образом, после прохождения этого сообщения, он будет фактически выдвигать коммит в рабочую область p4 при запуске git p4 submit в результате дубликат p4 представляет и испортил файлы. Я верю, что это происходит, когда я бегу git rebase --continue, затем git rebase --skip затем git p4 submit

Когда я проверяю журнал git, HEAD обычно опережает мастер по коммиту, но как?

А потом иногда ошибка снова исчезает, и я не могу точно определить условия, при которых она исчезает.

Как бы я начал понимать эту проблему?

Answer 1

Полагаю, я все еще не понимаю ваш рабочий процесс. Вы загружаете коммиты непосредственно в Perforce или в исходное git-репо, которое работает git p4 submit, Если вы делаете позже, то я думаю, что это ваша главная проблема. Вам нужно отправить локальные изменения непосредственно в Perorce, а затем синхронизировать все обратно с git p4 rebase, Когда вы делаете git p4 submitновые коммиты модифицируются перед тем, как их подталкивают к исполнению, поэтому вы не можете сначала перейти к другому git-репо.

Если ты всегда p4 submit с клиентского компьютера, который создал comit, ваша ошибка может быть вызвана каким-либо несоответствием имени пользователя / электронной почты на стороне Perforce. Каждый git commit sha1 основан на электронной почте автора и дате принятия (плюс другие вещи), если эти значения изменятся, то, скорее всего, git-p4 rebase сгенерирует другой sha1, чем тот, который у вас есть локально, и выдаст вам это сообщение об ошибке.

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

Таким образом, решение состоит в том, чтобы либо не изменять значения сообщений электронной почты на стороне производительности, либо что-либо еще, что может запутать git-p4, Если вы меняете электронные письма в процессе выполнения, то вы должны сохранять исходный файл сопоставления до тех пор, пока вы не импортируете все свои коммиты с нуля.