问题
I am having a problem with git p4 rebase and I don't know how to start diagnosing the issue, much less what the problem is.
So I have a git repo cloned from a perforce workspace by git-p4 and it's being used as a remote repo to serve as a bridge so a team can use git against one remote repo and then periodically, I can push the repo's changes back to the workspace.
And normally the workflow is either that the person is on the master branch, makes edits, git -a commits them, git pulls again, then git pushes them to the remote repo, or they make a branch, and then merge that branch back in when they're done and then pushes the master branch up to remote. They may occasionally push the branch up if they take more than a day.
When I push stuff back up to perforce, I run the following commands in the remote repo
git checkout -f
git clean -f
git p4 rebase --import-labels
git p4 submit -M --export-labels
git checkout -f
git clean -f
The remote repo is not bare, which is why I'm running checkout and clean before and after
Basically every now and again, After changes have been pushed back up, when I do a git p4 rebase, I get the following error
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
So I have a number of questions, here, when it's doing the git rebase, as part of git p4 rebase, it's reapplying a number of commits that have already been applied to the remote repo and which have been pushed back up to the workspace from a previous git p4 rebase. Where did the duplicate commits come from? Why is it still trying to replay them over the repo?
When I check the file in the working copy of the repo, it's the same as the workspace, because I haven't made any changes, since the last git p4 rebase. As a result git rebase --continue doesn't really do anything.
The only solution is to run git rebase --skip but when I do that, the same message comes up when I run git p4 rebase a subsequent time and I have to rerun git rebase --skip everytime. It's infuriating.
And occasionally, I'm not entirely sure how, after have gotten through this message, it will actually push the commit to the p4 workspace when I run git p4 submit resulting in duplicate p4 submits and messed up files. I believe it happens when I run git rebase --continue, then git rebase --skip then git p4 submit
When I check the git log, HEAD is usually ahead of master by a commit, but how?
And then occasionally the error disappears again, and I can't figure out exactly the conditions under which it disappears.
How would I even start to figure this problem out?
回答1:
I guess i'm still confused about your workflow. Are you pushing commits directly to Perforce, or to an origin git repo that is running git p4 submit. If you are doing the later, then I think that is your main problem. You need to push local changes directly to Perorce, and then sync everything back with git p4 rebase. When you do a git p4 submit, the new commits are modified before being pushed into perforce, that's why you can't push to another git repo first.
If you always p4 submit from the client machine that created the comit, your error may be caused by some type of mismatch with username/emails on the Perforce side. Each git commit sha1 is based using the author email and commit date, (plus other things), if these values change, then it's likely git-p4 rebase will generate a different sha1 than what you have locally and give you that error message.
git-p4 tries to compensate for this by creating a perforce username to email mapping file. I forget where this file is kept, but if you loose it, then git-p4 will get confused, and try to re-apply commits that you already have.
So the solution is either not to change emails values on the perforce side, or anything else that might confuse git-p4. If you change emails in perforce, then you must make sure you keep your original mapping file around until you re-import all of your commits from scratch.
来源：https://stackoverflow.com/questions/16106900/git-p4-rebase-attempts-to-reapply-past-commits