threads / discuss / 33744

3 way merge during git p4 rebase is attempting to reapply past commits

Subject: 3 way merge during git p4 rebase is attempting to reapply past commits

## tl;dr

3 messages between May 7, 2013 and May 8, 2013.

replies: 2people: 2as markdown or json

Christopher Yee Mon· May 7, 2013, 23:12 UTC · lore
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. Then I periodically run the following commands in a script to push those changes back to perforce.

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

Luke Diamand· May 8, 2013, 05:35 UTC · re: Christopher Yee Mon · lore

Re: 3 way merge during git p4 rebase is attempting to reapply past commits

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
Christopher Yee Mon· May 8, 2013, 14:32 UTC · re: Luke Diamand · lore

Re: 3 way merge during git p4 rebase is attempting to reapply past commits

git p4 rebase and git p4 submit don't work on a bare repo (at least it didn't for me) This is weird since there is a --bare option for git p4 clone, but then you can't do git p4 submit's on that bare repo back up to perforce?

I got an error stating:

git p4 rebase Performing incremental import into refs/remotes/p4/master git branch Depot paths: //depot/path.to/folder/ No changes to import! fatal: This operation must be run in a work tree Some files in your working directory are modified and different than what is in your index. You can use git update-index <filename> to bring the index up-to-date or stash away all your changes with git stash.

And I got this error for git p4 submit stating

Perforce checkout for depot path //depot/path.to/folder/ located at /home/user1/path/to/perforce.folder/ Synchronizing p4 checkout... ... - file(s) up-to-date. fatal: Not a git repository: '.' Command failed: ['git', 'rev-list', '--no-merges', 'remotes/p4/master..master']

http://stackoverflow.com/questions/15512357/how-to-run-git-p4-submit-on-a-bare-repo (The workaround described seemed particularly convoluted.)

My only (simple) workaround for that is doing the git checkout -f and git clean -f before and after doing git p4 rebase and git p4 submit ( http://stackoverflow.com/questions/15512700/replace-working-copy-of-git-repo-with-actual-contents-of-repo-in-git )

I've encountered so many errors over time that I can't trust to leave the operation scheduled, because some problem like this might crop up again.

On Wed, May 8, 2013 at 1:35 AM, Luke Diamand <luke@diamand.org> wrote:
Show 121 quoted lines
> On 08/05/13 00:12, Christopher Yee Mon wrote:
>>
>> 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
>
> :-)
>
>
>>
>> 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
>
>

← back to recent threads