git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Christopher Yee MonNext: Christopher Yee Mon
Message 2 of 3 in “3 way merge during git p4 rebase is attempting to reapply past commits”
  1. Christopher Yee MonMay 7, 2013
  2. Luke DiamandMay 8, 2013
  3. Christopher Yee MonMay 8, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.