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 l...@diamand.org wrote: 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, inmodule 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
Re: git p4 submit failing
I reset all the files to be lf. I also forced all the windows users IDEs to use Unix endings. I haven't seen that error since then Thanks for the assistance On Thu, Apr 18, 2013 at 7:43 PM, Pete Wyckoff p...@padd.com wrote: christopher.yee...@gmail.com wrote on Thu, 18 Apr 2013 11:24 -0500: The issue is caused by the line endings. I retested the problem with a different file and in this case, the error is caused by the line endings of the file checked out in the perforce workspace being win-style crlf, and the line endings of the file in the git repo being unix style lf. (In this scenario, I took out the .gitattributes, core.autocrlf was set to false and LineEnd was set to share) In this case, I checked out the file in perforce, ran dos2unix against it, and submitted that, then ran git p4 submit and it worked. I noticed that the error is caused by the git apply failing in the def applyCommit(self, id) function at lines 1296-1305. diffcmd = git format-patch -k --stdout \%s^\..\%s\ % (id, id) patchcmd = diffcmd + | git apply tryPatchCmd = patchcmd + --check - applyPatchCmd = patchcmd + --check --apply - patch_succeeded = True if os.system(tryPatchCmd) != 0: fixed_rcs_keywords = False patch_succeeded = False print Unfortunately applying the change failed! So most likely in git apply command, it can't find the changes because of the line endings being different between them. I couldn't find a parameter that would magically make it work. When I added --verbose to git apply the output only says: error: while searching for: and then the first lines of the first diff That seems like exactly the correct diagnosis of the problem. What to do about it, I'm not so sure. We could suggest that people use the same line-ending conventions in both git and p4 land. This is easy if they are both lf. But, if crlf is preferred, do you know how to configure git to use crlf line endings? Does that fix it? There's also the config setting apply.ignorewhitespace; not sure if that would allow the apply step to apply an lf-ending patch to the crlf-ending p4 workspace. -- Pete Hello Simon, I have CCed you to alert you to the possible bug. Any assistance would be appreciated. On Sat, Apr 13, 2013 at 5:09 PM, Christopher Yee Mon christopher.yee...@gmail.com wrote: Yes this is the case. Many of the files have crlf endings. core.autocrlf was recently set to input. I can't remember the timeline exactly though, but in addition to this, I have a .gitattributes file with the default set to text=auto (* text=auto) and the php files set to text eol=lf (*.php text eol=lf) Also my perforce workspace's LineEnd setting is set to Share. I've experienced the behavior in both .php and .xml files though Before all of this started I had core.autocrlf set to false, and no .gitattributes file and perforce workspace's LineEnd was set to the default, but I got a conflict where the only difference was the line endings, so I changed things to the way they are now. Any recommendations? Should I change everything back the way it was? On Sat, Apr 13, 2013 at 5:51 PM, Pete Wyckoff p...@padd.com wrote: l...@diamand.org wrote on Thu, 11 Apr 2013 21:19 +0100: Just a thought, but check the files that are failing to see if they've got RCS keywords in them ($Id$, $File$, $Date$, etc). These cause all sorts of nasty problems. That's assuming it's definitely not a CRLF line ending problem on Windows. I had recently debugged a similar-looking problem where core.autocrlf was set to input. Christopher, if you have this set and/or the .xml files have ^M (CRLF) line endings, please let us know. -- Pete On Thu, Apr 11, 2013 at 8:01 PM, Christopher Yee Mon christopher.yee...@gmail.com wrote: I tried running git p4 submit on a repo that I've been running as an interim bridge between git and perforce. Multiple people are using the repo as a remote and its being periodically submitted back to perforce. It's been working mostly fine. Then one day out of the blue I get this error. I can no longer push any git commits to perforce. (This is from the remote repo which I am pushing back to perforce) user@hostname:~/Source/code$ git p4 submit -M --export-labels Perforce checkout for depot path //depot/perforce/workspace/ located at /home/user/Source/git-p4-area/perforce/workspace/ Synchronizing p4 checkout... ... - file(s) up-to-date. Applying ffa390f comments in config xml files //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/second.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/third.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/forth.xml
3 way merge during git p4 rebase is attempting to reapply past commits
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git p4 submit failing
The issue is caused by the line endings. I retested the problem with a different file and in this case, the error is caused by the line endings of the file checked out in the perforce workspace being win-style crlf, and the line endings of the file in the git repo being unix style lf. (In this scenario, I took out the .gitattributes, core.autocrlf was set to false and LineEnd was set to share) In this case, I checked out the file in perforce, ran dos2unix against it, and submitted that, then ran git p4 submit and it worked. I noticed that the error is caused by the git apply failing in the def applyCommit(self, id) function at lines 1296-1305. diffcmd = git format-patch -k --stdout \%s^\..\%s\ % (id, id) patchcmd = diffcmd + | git apply tryPatchCmd = patchcmd + --check - applyPatchCmd = patchcmd + --check --apply - patch_succeeded = True if os.system(tryPatchCmd) != 0: fixed_rcs_keywords = False patch_succeeded = False print Unfortunately applying the change failed! So most likely in git apply command, it can't find the changes because of the line endings being different between them. I couldn't find a parameter that would magically make it work. When I added --verbose to git apply the output only says: error: while searching for: and then the first lines of the first diff Hello Simon, I have CCed you to alert you to the possible bug. Any assistance would be appreciated. On Sat, Apr 13, 2013 at 5:09 PM, Christopher Yee Mon christopher.yee...@gmail.com wrote: Yes this is the case. Many of the files have crlf endings. core.autocrlf was recently set to input. I can't remember the timeline exactly though, but in addition to this, I have a .gitattributes file with the default set to text=auto (* text=auto) and the php files set to text eol=lf (*.php text eol=lf) Also my perforce workspace's LineEnd setting is set to Share. I've experienced the behavior in both .php and .xml files though Before all of this started I had core.autocrlf set to false, and no .gitattributes file and perforce workspace's LineEnd was set to the default, but I got a conflict where the only difference was the line endings, so I changed things to the way they are now. Any recommendations? Should I change everything back the way it was? On Sat, Apr 13, 2013 at 5:51 PM, Pete Wyckoff p...@padd.com wrote: l...@diamand.org wrote on Thu, 11 Apr 2013 21:19 +0100: Just a thought, but check the files that are failing to see if they've got RCS keywords in them ($Id$, $File$, $Date$, etc). These cause all sorts of nasty problems. That's assuming it's definitely not a CRLF line ending problem on Windows. I had recently debugged a similar-looking problem where core.autocrlf was set to input. Christopher, if you have this set and/or the .xml files have ^M (CRLF) line endings, please let us know. -- Pete On Thu, Apr 11, 2013 at 8:01 PM, Christopher Yee Mon christopher.yee...@gmail.com wrote: I tried running git p4 submit on a repo that I've been running as an interim bridge between git and perforce. Multiple people are using the repo as a remote and its being periodically submitted back to perforce. It's been working mostly fine. Then one day out of the blue I get this error. I can no longer push any git commits to perforce. (This is from the remote repo which I am pushing back to perforce) user@hostname:~/Source/code$ git p4 submit -M --export-labels Perforce checkout for depot path //depot/perforce/workspace/ located at /home/user/Source/git-p4-area/perforce/workspace/ Synchronizing p4 checkout... ... - file(s) up-to-date. Applying ffa390f comments in config xml files //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/second.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/third.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/fifth.xml#1 - opened for edit error: patch failed: sub/folder/structure/first.xml:1 error: sub/folder/structure/first.xml: patch does not apply error: patch failed: sub/folder/structure/second.xml:1 error: sub/folder/structure/second.xml: patch does not apply error: patch failed: sub/folder/structure/third.xml:1 error: sub/folder/structure/third.xml: patch does not apply error: patch failed: sub/folder/structure/forth.xml:1 error: sub/folder/structure/forth.xml: patch does not apply error: patch failed: sub/folder/structure/fifth.xml:1 error: sub/folder/structure/fifth.xml: patch does not apply Unfortunately applying the change failed! //depot/perforce/workspace/sub/folder/structure/first.xml#1 - was edit, reverted //depot/perforce/workspace/sub/folder/structure/second.xml#3 - was edit, reverted
git p4 submit failing
I tried running git p4 submit on a repo that I've been running as an interim bridge between git and perforce. Multiple people are using the repo as a remote and its being periodically submitted back to perforce. It's been working mostly fine. Then one day out of the blue I get this error. I can no longer push any git commits to perforce. (This is from the remote repo which I am pushing back to perforce) user@hostname:~/Source/code$ git p4 submit -M --export-labels Perforce checkout for depot path //depot/perforce/workspace/ located at /home/user/Source/git-p4-area/perforce/workspace/ Synchronizing p4 checkout... ... - file(s) up-to-date. Applying ffa390f comments in config xml files //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/second.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/third.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - opened for edit //depot/perforce/workspace/sub/folder/structure/fifth.xml#1 - opened for edit error: patch failed: sub/folder/structure/first.xml:1 error: sub/folder/structure/first.xml: patch does not apply error: patch failed: sub/folder/structure/second.xml:1 error: sub/folder/structure/second.xml: patch does not apply error: patch failed: sub/folder/structure/third.xml:1 error: sub/folder/structure/third.xml: patch does not apply error: patch failed: sub/folder/structure/forth.xml:1 error: sub/folder/structure/forth.xml: patch does not apply error: patch failed: sub/folder/structure/fifth.xml:1 error: sub/folder/structure/fifth.xml: patch does not apply Unfortunately applying the change failed! //depot/perforce/workspace/sub/folder/structure/first.xml#1 - was edit, reverted //depot/perforce/workspace/sub/folder/structure/second.xml#3 - was edit, reverted //depot/perforce/workspace/sub/folder/structure/third.xml#3 - was edit, reverted //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - was edit, reverted //depot/perforce/workspace/sub/folder/structure/fifth.xml#3 - was edit, reverted No commits applied. I thought it could be the .gitattributes setting that I had which was this at the time was this: * text eol=lf My global core.autocrlf setting was also false. So I remade a new remote repo, and changed core.autocrlf to input and changed .gitattributes to this * text=auto *.php text eol=lf *.pl text eol=lf *.pm text eol=lf *.sh text eol=lf *.vbs text eol=crlf *.bat text eol=crlf *.ps1 text eol=crlf *.bdb binary *.mtr binary Then I started to realize that it could just be the files in the initial commit that are suspect, because when i made edits to other files in the repo then tried to push them back with git p4 submit, those files submitted successfully But the files in the commit where I initially got the failure still give me this problem. Here's what it looks like when I retested with a fresh git repo cloned from perforce with git p4 clone and tried to do the git p4 submit with verbose turned on on only one of the suspecting files user@hostname:/code$ git p4 submit -M --export-labels --verbose Reading pipe: git name-rev HEAD Reading pipe: ['git', 'config', 'git-p4.allowSubmit'] Reading pipe: git rev-parse --symbolic --remotes Reading pipe: git rev-parse p4/master Reading pipe: git cat-file commit 0457c7589ea679dcc0c9114b34f8f30bc2ee08cf Reading pipe: git cat-file commit HEAD~0 Reading pipe: git cat-file commit HEAD~1 Reading pipe: ['git', 'config', 'git-p4.conflict'] Origin branch is remotes/p4/master Reading pipe: ['git', 'config', '--bool', 'git-p4.useclientspec'] Opening pipe: ['p4', '-G', 'where', '//depot/perforce/workspace/...'] Perforce checkout for depot path //depot/perforce/workspace/ located at /home/user/Source/git-p4-area/perforce/workspace/ Synchronizing p4 checkout... ... - file(s) up-to-date. Opening pipe: p4 -G opened ... Reading pipe: ['git', 'rev-list', '--no-merges', 'remotes/p4/master..master'] Reading pipe: ['git', 'config', '--bool', 'git-p4.skipUserNameCheck'] Reading pipe: ['git', 'config', 'git-p4.detectCopies'] Reading pipe: ['git', 'config', '--bool', 'git-p4.detectCopiesHarder'] Reading pipe: ['git', 'show', '-s', '--format=format:%h %s', 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e'] Applying ef3b95f making test change Opening pipe: p4 -G users Reading pipe: ['git', 'log', '--max-count=1', '--format=%ae', 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e'] Reading pipe: git diff-tree -r -M ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e^ ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit stdin:17: trailing whitespace. !-- comment line 1 -- stdin:18: trailing whitespace. !-- comment line 2 -- stdin:19: trailing whitespace. !-- comment line 3 -- error: patch failed: sub/folder/structure/first.xml:1 error: sub/folder/structure/first.xml: patch does not apply Unfortunately applying the change failed! Reading pipe: ['git', 'config',
