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 <pw@xxxxxxxx> wrote: > christopher.yeemon@xxxxxxxxx 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.yeemon@xxxxxxxxx> 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 <pw@xxxxxxxx> wrote: >> >> luke@xxxxxxxxxxx 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.yeemon@xxxxxxxxx> 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 >> >>> > //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', '--bool', 'git-p4.attemptRCSCleanup'] >> >>> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - was edit, reverted >> >>> > No commits applied. >> >>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.exportLabels'] >> >>> > Opening pipe: ['p4', '-G', 'labels', '//depot/ipstor.maple/automation/...'] >> >>> > Reading pipe: ['git', 'tag'] >> >>> > Reading pipe: ['git', 'config', 'git-p4.labelExportRegexp'] >> >>> > >> >>> > In any case, I'm starting to think it could be a legitimate bug, which >> >>> > is why I am submitting it here. Does anyone have any ideas for >> >>> > suggestions on diagnosing what could be wrong? >> >>> > -- >> >>> > To unsubscribe from this list: send the line "unsubscribe git" in >> >>> > the body of a message to majordomo@xxxxxxxxxxxxxxx >> >>> > More majordomo info at http://vger.kernel.org/majordomo-info.html >> >>> -- >> >>> To unsubscribe from this list: send the line "unsubscribe git" in >> >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >>> >> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html