Re: 3 way merge during git p4 rebase is attempting to reapply past commits
- From
Luke Diamand <luke@diamand.org>
- Date
- May 8, 2013, 05:35 UTC
- Message-ID
- <5189E42E.8050107@diamand.org>
- In-Reply-To
- <CAG4Fb8f8vxbqwnCn1B9EfZu3sM-3-wQ2dqcR+BezPaf_XEy5Xw@mail.gmail.com>
On 08/05/13 00:12, Christopher Yee Mon wrote:
Show 6 quoted lines
> Hello, > > I have a setup where I have a remote non-bare repo cloned from a > perforce workspace. It is used as a remote repo that people clone into > their own user repos, make commits to, then push back into the remote > repo.
Why is your p4 clone non-bare? I thought pushing into a non-bare repo tended to cause problems?
> Then I periodically run the following commands in a script to > push those changes back to perforce.
% man cron
:-)
Show 95 quoted lines
>
> git checkout -f
> git clean -f
> git p4 rebase --import-labels
> git p4 submit -M --export-labels
> git checkout -f
> git clean -f
>
> Sometimes, always after commits from one user's machine specifically,
> I get the following error below when pushing back to perforce at the
> remote repo. It seems to happen randomly, or at least intermittently,
> since I often can't discern any major error during git committing to
> the remote repo that precipitates this error. It does happen pretty
> reliably when I get a file conflict that I resolve and fix during
> committing though.
>
> 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
>
> The patch is usually one that is already in the remote git repo and in
> perforce. At that point I have to run git rebase --skip, to skip the
> patch, then rerun the commands in the script again. Sometimes it's
> multiple patches that cause this problem and I have to run git rebase
> --skip repeatedly. When I check the working copy of the remote repo, I
> don't see any changes, no conflict markers, just the file.
>
> The real problem happens when I run git rebase --continue. Usually I
> end up with repeated submits in perforce when I do that, which is
> obviously a corruption of data.
>
> It sounds a lot like this error, except I don't know how git p4 is
> branching, so I don't know how to diagnose it.
>
> http://stackoverflow.com/questions/4033009/git-rebase-conflicts-keep-blocking-progress
>
> I also asked stack overflow and someone there said it's probably the
> perforce user being different from the git user info, so I had all the
> git users switch to having the same info as the perforce user info and
> that did NOT solve the problem.
>
> http://stackoverflow.com/questions/16106900/git-p4-rebase-attempts-to-reapply-past-commits
>
> I'm not sure what could possibly be causing this or how to fix it.
> Does anyone have any ideas?
>
> Thanks
> Christopher Yee Mon
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html