{"thread":{"id":"33481","subject":"git p4 submit failing","startedAt":"2013-04-11T19:01:03Z","lastAt":"2013-05-07T22:36:59Z","messageCount":6,"participants":["Christopher Yee Mon","Luke Diamand","Pete Wyckoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"213992","messageId":"CAG4Fb8ejKCpUqZ+YVQT=S2-p6YcNo5+s81j2Jrx8q1ijtu8yqw@mail.gmail.com","threadId":"33481","inReplyTo":null,"subject":"git p4 submit failing","fromName":"Christopher Yee Mon","fromEmail":"christopher.yeemon@gmail.com","sentAt":"2013-04-11T19:01:03Z","receivedAt":"2013-04-11T19:01:03Z","isPatch":false,"sender":{"key":"christopher.yeemon@gmail.com","avatar":null},"body":"I tried running git p4 submit on a repo that I've been running as an\ninterim bridge between git and perforce. Multiple people are using the\nrepo as a remote and its being periodically submitted back to\nperforce.\n\nIt's been working mostly fine. Then one day out of the blue I get this\nerror. I can no longer push any git commits to perforce. (This is from\nthe remote repo which I am pushing back to perforce)\n\nuser@hostname:~/Source/code$ git p4 submit -M --export-labels\nPerforce checkout for depot path //depot/perforce/workspace/ located\nat /home/user/Source/git-p4-area/perforce/workspace/\nSynchronizing p4 checkout...\n... - file(s) up-to-date.\nApplying ffa390f comments in config xml files\n//depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n//depot/perforce/workspace/sub/folder/structure/second.xml#3 - opened for edit\n//depot/perforce/workspace/sub/folder/structure/third.xml#3 - opened for edit\n//depot/perforce/workspace/sub/folder/structure/forth.xml#3 - opened for edit\n//depot/perforce/workspace/sub/folder/structure/fifth.xml#1 - opened for edit\nerror: patch failed: sub/folder/structure/first.xml:1\nerror: sub/folder/structure/first.xml: patch does not apply\nerror: patch failed: sub/folder/structure/second.xml:1\nerror: sub/folder/structure/second.xml: patch does not apply\nerror: patch failed: sub/folder/structure/third.xml:1\nerror: sub/folder/structure/third.xml: patch does not apply\nerror: patch failed: sub/folder/structure/forth.xml:1\nerror: sub/folder/structure/forth.xml: patch does not apply\nerror: patch failed: sub/folder/structure/fifth.xml:1\nerror: sub/folder/structure/fifth.xml: patch does not apply\nUnfortunately applying the change failed!\n//depot/perforce/workspace/sub/folder/structure/first.xml#1 - was edit, reverted\n//depot/perforce/workspace/sub/folder/structure/second.xml#3 - was\nedit, reverted\n//depot/perforce/workspace/sub/folder/structure/third.xml#3 - was edit, reverted\n//depot/perforce/workspace/sub/folder/structure/forth.xml#3 - was edit, reverted\n//depot/perforce/workspace/sub/folder/structure/fifth.xml#3 - was edit, reverted\nNo commits applied.\n\nI thought it could be the .gitattributes setting that I had which was\nthis at the time was this:\n\n* text eol=lf\n\nMy global core.autocrlf setting was also false.\n\nSo I remade a new remote repo, and changed core.autocrlf to input and\nchanged .gitattributes to this\n\n* text=auto\n\n*.php text eol=lf\n*.pl text eol=lf\n*.pm text eol=lf\n*.sh text eol=lf\n\n*.vbs text eol=crlf\n*.bat text eol=crlf\n*.ps1 text eol=crlf\n\n*.bdb binary\n*.mtr binary\n\nThen I started to realize that it could just be the files in the\ninitial commit that are suspect, because when i made edits to other\nfiles in the repo then tried to push them back with git p4 submit,\nthose files submitted successfully  But the files in the commit where\nI initially got the failure still give me this problem.\n\nHere's what it looks like when I retested with a fresh git repo cloned\nfrom perforce with git p4 clone and tried to do the git p4 submit with\nverbose turned on on only one of the suspecting files\n\nuser@hostname:/code$ git p4 submit -M --export-labels --verbose\nReading pipe: git name-rev HEAD\nReading pipe: ['git', 'config', 'git-p4.allowSubmit']\nReading pipe: git rev-parse --symbolic --remotes\nReading pipe: git rev-parse p4/master\nReading pipe: git cat-file commit 0457c7589ea679dcc0c9114b34f8f30bc2ee08cf\nReading pipe: git cat-file commit HEAD~0\nReading pipe: git cat-file commit HEAD~1\nReading pipe: ['git', 'config', 'git-p4.conflict']\nOrigin branch is remotes/p4/master\nReading pipe: ['git', 'config', '--bool', 'git-p4.useclientspec']\nOpening pipe: ['p4', '-G', 'where', '//depot/perforce/workspace/...']\nPerforce checkout for depot path //depot/perforce/workspace/ located\nat /home/user/Source/git-p4-area/perforce/workspace/\nSynchronizing p4 checkout...\n... - file(s) up-to-date.\nOpening pipe: p4 -G opened ...\nReading pipe: ['git', 'rev-list', '--no-merges', 'remotes/p4/master..master']\nReading pipe: ['git', 'config', '--bool', 'git-p4.skipUserNameCheck']\nReading pipe: ['git', 'config', 'git-p4.detectCopies']\nReading pipe: ['git', 'config', '--bool', 'git-p4.detectCopiesHarder']\nReading pipe: ['git', 'show', '-s', '--format=format:%h %s',\n'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\nApplying ef3b95f making test change\nOpening pipe: p4 -G users\nReading pipe: ['git', 'log', '--max-count=1', '--format=%ae',\n'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\nReading pipe: git diff-tree -r -M\n\"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e^\"\n\"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e\"\n//depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n<stdin>:17: trailing whitespace.\n<!-- comment line 1 -->\n<stdin>:18: trailing whitespace.\n<!-- comment line 2 -->\n<stdin>:19: trailing whitespace.\n<!-- comment line 3 -->\nerror: patch failed: sub/folder/structure/first.xml:1\nerror: sub/folder/structure/first.xml: patch does not apply\nUnfortunately applying the change failed!\nReading pipe: ['git', 'config', '--bool', 'git-p4.attemptRCSCleanup']\n//depot/perforce/workspace/sub/folder/structure/first.xml#3 - was edit, reverted\nNo commits applied.\nReading pipe: ['git', 'config', '--bool', 'git-p4.exportLabels']\nOpening pipe: ['p4', '-G', 'labels', '//depot/ipstor.maple/automation/...']\nReading pipe: ['git', 'tag']\nReading pipe: ['git', 'config', 'git-p4.labelExportRegexp']\n\nIn any case, I'm starting to think it could be a legitimate bug, which\nis why I am submitting it here. Does anyone have any ideas for\nsuggestions on diagnosing what could be wrong?\n"},{"id":"214002","messageId":"CAE5ih78rw1_oE2SFQFnfUSfRfDGRW0pVC7TL1qgxwdcOFbBdCw@mail.gmail.com","threadId":"33481","inReplyTo":"CAG4Fb8ejKCpUqZ+YVQT=S2-p6YcNo5+s81j2Jrx8q1ijtu8yqw@mail.gmail.com","subject":"Re: git p4 submit failing","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2013-04-11T20:19:42Z","receivedAt":"2013-04-11T20:19:42Z","isPatch":false,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"Just a thought, but check the files that are failing to see if they've\ngot RCS keywords in them ($Id$, $File$, $Date$, etc). These cause all\nsorts of nasty problems.\n\nThat's assuming it's definitely not a CRLF line ending problem on Windows.\n\nOn Thu, Apr 11, 2013 at 8:01 PM, Christopher Yee Mon\n<christopher.yeemon@gmail.com> wrote:\n> I tried running git p4 submit on a repo that I've been running as an\n> interim bridge between git and perforce. Multiple people are using the\n> repo as a remote and its being periodically submitted back to\n> perforce.\n>\n> It's been working mostly fine. Then one day out of the blue I get this\n> error. I can no longer push any git commits to perforce. (This is from\n> the remote repo which I am pushing back to perforce)\n>\n> user@hostname:~/Source/code$ git p4 submit -M --export-labels\n> Perforce checkout for depot path //depot/perforce/workspace/ located\n> at /home/user/Source/git-p4-area/perforce/workspace/\n> Synchronizing p4 checkout...\n> ... - file(s) up-to-date.\n> Applying ffa390f comments in config xml files\n> //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n> //depot/perforce/workspace/sub/folder/structure/second.xml#3 - opened for edit\n> //depot/perforce/workspace/sub/folder/structure/third.xml#3 - opened for edit\n> //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - opened for edit\n> //depot/perforce/workspace/sub/folder/structure/fifth.xml#1 - opened for edit\n> error: patch failed: sub/folder/structure/first.xml:1\n> error: sub/folder/structure/first.xml: patch does not apply\n> error: patch failed: sub/folder/structure/second.xml:1\n> error: sub/folder/structure/second.xml: patch does not apply\n> error: patch failed: sub/folder/structure/third.xml:1\n> error: sub/folder/structure/third.xml: patch does not apply\n> error: patch failed: sub/folder/structure/forth.xml:1\n> error: sub/folder/structure/forth.xml: patch does not apply\n> error: patch failed: sub/folder/structure/fifth.xml:1\n> error: sub/folder/structure/fifth.xml: patch does not apply\n> Unfortunately applying the change failed!\n> //depot/perforce/workspace/sub/folder/structure/first.xml#1 - was edit, reverted\n> //depot/perforce/workspace/sub/folder/structure/second.xml#3 - was\n> edit, reverted\n> //depot/perforce/workspace/sub/folder/structure/third.xml#3 - was edit, reverted\n> //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - was edit, reverted\n> //depot/perforce/workspace/sub/folder/structure/fifth.xml#3 - was edit, reverted\n> No commits applied.\n>\n> I thought it could be the .gitattributes setting that I had which was\n> this at the time was this:\n>\n> * text eol=lf\n>\n> My global core.autocrlf setting was also false.\n>\n> So I remade a new remote repo, and changed core.autocrlf to input and\n> changed .gitattributes to this\n>\n> * text=auto\n>\n> *.php text eol=lf\n> *.pl text eol=lf\n> *.pm text eol=lf\n> *.sh text eol=lf\n>\n> *.vbs text eol=crlf\n> *.bat text eol=crlf\n> *.ps1 text eol=crlf\n>\n> *.bdb binary\n> *.mtr binary\n>\n> Then I started to realize that it could just be the files in the\n> initial commit that are suspect, because when i made edits to other\n> files in the repo then tried to push them back with git p4 submit,\n> those files submitted successfully  But the files in the commit where\n> I initially got the failure still give me this problem.\n>\n> Here's what it looks like when I retested with a fresh git repo cloned\n> from perforce with git p4 clone and tried to do the git p4 submit with\n> verbose turned on on only one of the suspecting files\n>\n> user@hostname:/code$ git p4 submit -M --export-labels --verbose\n> Reading pipe: git name-rev HEAD\n> Reading pipe: ['git', 'config', 'git-p4.allowSubmit']\n> Reading pipe: git rev-parse --symbolic --remotes\n> Reading pipe: git rev-parse p4/master\n> Reading pipe: git cat-file commit 0457c7589ea679dcc0c9114b34f8f30bc2ee08cf\n> Reading pipe: git cat-file commit HEAD~0\n> Reading pipe: git cat-file commit HEAD~1\n> Reading pipe: ['git', 'config', 'git-p4.conflict']\n> Origin branch is remotes/p4/master\n> Reading pipe: ['git', 'config', '--bool', 'git-p4.useclientspec']\n> Opening pipe: ['p4', '-G', 'where', '//depot/perforce/workspace/...']\n> Perforce checkout for depot path //depot/perforce/workspace/ located\n> at /home/user/Source/git-p4-area/perforce/workspace/\n> Synchronizing p4 checkout...\n> ... - file(s) up-to-date.\n> Opening pipe: p4 -G opened ...\n> Reading pipe: ['git', 'rev-list', '--no-merges', 'remotes/p4/master..master']\n> Reading pipe: ['git', 'config', '--bool', 'git-p4.skipUserNameCheck']\n> Reading pipe: ['git', 'config', 'git-p4.detectCopies']\n> Reading pipe: ['git', 'config', '--bool', 'git-p4.detectCopiesHarder']\n> Reading pipe: ['git', 'show', '-s', '--format=format:%h %s',\n> 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\n> Applying ef3b95f making test change\n> Opening pipe: p4 -G users\n> Reading pipe: ['git', 'log', '--max-count=1', '--format=%ae',\n> 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\n> Reading pipe: git diff-tree -r -M\n> \"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e^\"\n> \"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e\"\n> //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n> <stdin>:17: trailing whitespace.\n> <!-- comment line 1 -->\n> <stdin>:18: trailing whitespace.\n> <!-- comment line 2 -->\n> <stdin>:19: trailing whitespace.\n> <!-- comment line 3 -->\n> error: patch failed: sub/folder/structure/first.xml:1\n> error: sub/folder/structure/first.xml: patch does not apply\n> Unfortunately applying the change failed!\n> Reading pipe: ['git', 'config', '--bool', 'git-p4.attemptRCSCleanup']\n> //depot/perforce/workspace/sub/folder/structure/first.xml#3 - was edit, reverted\n> No commits applied.\n> Reading pipe: ['git', 'config', '--bool', 'git-p4.exportLabels']\n> Opening pipe: ['p4', '-G', 'labels', '//depot/ipstor.maple/automation/...']\n> Reading pipe: ['git', 'tag']\n> Reading pipe: ['git', 'config', 'git-p4.labelExportRegexp']\n>\n> In any case, I'm starting to think it could be a legitimate bug, which\n> is why I am submitting it here. Does anyone have any ideas for\n> suggestions on diagnosing what could be wrong?\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"214145","messageId":"20130413215110.GA5370@padd.com","threadId":"33481","inReplyTo":"CAE5ih78rw1_oE2SFQFnfUSfRfDGRW0pVC7TL1qgxwdcOFbBdCw@mail.gmail.com","subject":"Re: git p4 submit failing","fromName":"Pete Wyckoff","fromEmail":"pw@padd.com","sentAt":"2013-04-13T21:51:10Z","receivedAt":"2013-04-13T21:51:10Z","isPatch":false,"sender":{"key":"pw@padd.com","avatar":null},"body":"luke@diamand.org wrote on Thu, 11 Apr 2013 21:19 +0100:\n> Just a thought, but check the files that are failing to see if they've\n> got RCS keywords in them ($Id$, $File$, $Date$, etc). These cause all\n> sorts of nasty problems.\n> \n> That's assuming it's definitely not a CRLF line ending problem on Windows.\n\nI had recently debugged a similar-looking problem\nwhere core.autocrlf was set to \"input\".\n\nChristopher, if you have this set and/or the .xml files\nhave ^M (CRLF) line endings, please let us know.\n\n\t\t-- Pete\n\n> \n> On Thu, Apr 11, 2013 at 8:01 PM, Christopher Yee Mon\n> <christopher.yeemon@gmail.com> wrote:\n> > I tried running git p4 submit on a repo that I've been running as an\n> > interim bridge between git and perforce. Multiple people are using the\n> > repo as a remote and its being periodically submitted back to\n> > perforce.\n> >\n> > It's been working mostly fine. Then one day out of the blue I get this\n> > error. I can no longer push any git commits to perforce. (This is from\n> > the remote repo which I am pushing back to perforce)\n> >\n> > user@hostname:~/Source/code$ git p4 submit -M --export-labels\n> > Perforce checkout for depot path //depot/perforce/workspace/ located\n> > at /home/user/Source/git-p4-area/perforce/workspace/\n> > Synchronizing p4 checkout...\n> > ... - file(s) up-to-date.\n> > Applying ffa390f comments in config xml files\n> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n> > //depot/perforce/workspace/sub/folder/structure/second.xml#3 - opened for edit\n> > //depot/perforce/workspace/sub/folder/structure/third.xml#3 - opened for edit\n> > //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - opened for edit\n> > //depot/perforce/workspace/sub/folder/structure/fifth.xml#1 - opened for edit\n> > error: patch failed: sub/folder/structure/first.xml:1\n> > error: sub/folder/structure/first.xml: patch does not apply\n> > error: patch failed: sub/folder/structure/second.xml:1\n> > error: sub/folder/structure/second.xml: patch does not apply\n> > error: patch failed: sub/folder/structure/third.xml:1\n> > error: sub/folder/structure/third.xml: patch does not apply\n> > error: patch failed: sub/folder/structure/forth.xml:1\n> > error: sub/folder/structure/forth.xml: patch does not apply\n> > error: patch failed: sub/folder/structure/fifth.xml:1\n> > error: sub/folder/structure/fifth.xml: patch does not apply\n> > Unfortunately applying the change failed!\n> > //depot/perforce/workspace/sub/folder/structure/first.xml#1 - was edit, reverted\n> > //depot/perforce/workspace/sub/folder/structure/second.xml#3 - was\n> > edit, reverted\n> > //depot/perforce/workspace/sub/folder/structure/third.xml#3 - was edit, reverted\n> > //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - was edit, reverted\n> > //depot/perforce/workspace/sub/folder/structure/fifth.xml#3 - was edit, reverted\n> > No commits applied.\n> >\n> > I thought it could be the .gitattributes setting that I had which was\n> > this at the time was this:\n> >\n> > * text eol=lf\n> >\n> > My global core.autocrlf setting was also false.\n> >\n> > So I remade a new remote repo, and changed core.autocrlf to input and\n> > changed .gitattributes to this\n> >\n> > * text=auto\n> >\n> > *.php text eol=lf\n> > *.pl text eol=lf\n> > *.pm text eol=lf\n> > *.sh text eol=lf\n> >\n> > *.vbs text eol=crlf\n> > *.bat text eol=crlf\n> > *.ps1 text eol=crlf\n> >\n> > *.bdb binary\n> > *.mtr binary\n> >\n> > Then I started to realize that it could just be the files in the\n> > initial commit that are suspect, because when i made edits to other\n> > files in the repo then tried to push them back with git p4 submit,\n> > those files submitted successfully  But the files in the commit where\n> > I initially got the failure still give me this problem.\n> >\n> > Here's what it looks like when I retested with a fresh git repo cloned\n> > from perforce with git p4 clone and tried to do the git p4 submit with\n> > verbose turned on on only one of the suspecting files\n> >\n> > user@hostname:/code$ git p4 submit -M --export-labels --verbose\n> > Reading pipe: git name-rev HEAD\n> > Reading pipe: ['git', 'config', 'git-p4.allowSubmit']\n> > Reading pipe: git rev-parse --symbolic --remotes\n> > Reading pipe: git rev-parse p4/master\n> > Reading pipe: git cat-file commit 0457c7589ea679dcc0c9114b34f8f30bc2ee08cf\n> > Reading pipe: git cat-file commit HEAD~0\n> > Reading pipe: git cat-file commit HEAD~1\n> > Reading pipe: ['git', 'config', 'git-p4.conflict']\n> > Origin branch is remotes/p4/master\n> > Reading pipe: ['git', 'config', '--bool', 'git-p4.useclientspec']\n> > Opening pipe: ['p4', '-G', 'where', '//depot/perforce/workspace/...']\n> > Perforce checkout for depot path //depot/perforce/workspace/ located\n> > at /home/user/Source/git-p4-area/perforce/workspace/\n> > Synchronizing p4 checkout...\n> > ... - file(s) up-to-date.\n> > Opening pipe: p4 -G opened ...\n> > Reading pipe: ['git', 'rev-list', '--no-merges', 'remotes/p4/master..master']\n> > Reading pipe: ['git', 'config', '--bool', 'git-p4.skipUserNameCheck']\n> > Reading pipe: ['git', 'config', 'git-p4.detectCopies']\n> > Reading pipe: ['git', 'config', '--bool', 'git-p4.detectCopiesHarder']\n> > Reading pipe: ['git', 'show', '-s', '--format=format:%h %s',\n> > 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\n> > Applying ef3b95f making test change\n> > Opening pipe: p4 -G users\n> > Reading pipe: ['git', 'log', '--max-count=1', '--format=%ae',\n> > 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\n> > Reading pipe: git diff-tree -r -M\n> > \"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e^\"\n> > \"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e\"\n> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n> > <stdin>:17: trailing whitespace.\n> > <!-- comment line 1 -->\n> > <stdin>:18: trailing whitespace.\n> > <!-- comment line 2 -->\n> > <stdin>:19: trailing whitespace.\n> > <!-- comment line 3 -->\n> > error: patch failed: sub/folder/structure/first.xml:1\n> > error: sub/folder/structure/first.xml: patch does not apply\n> > Unfortunately applying the change failed!\n> > Reading pipe: ['git', 'config', '--bool', 'git-p4.attemptRCSCleanup']\n> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - was edit, reverted\n> > No commits applied.\n> > Reading pipe: ['git', 'config', '--bool', 'git-p4.exportLabels']\n> > Opening pipe: ['p4', '-G', 'labels', '//depot/ipstor.maple/automation/...']\n> > Reading pipe: ['git', 'tag']\n> > Reading pipe: ['git', 'config', 'git-p4.labelExportRegexp']\n> >\n> > In any case, I'm starting to think it could be a legitimate bug, which\n> > is why I am submitting it here. Does anyone have any ideas for\n> > suggestions on diagnosing what could be wrong?\n> > --\n> > To unsubscribe from this list: send the line \"unsubscribe git\" in\n> > the body of a message to majordomo@vger.kernel.org\n> > More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"214732","messageId":"CAG4Fb8cxdCGvzAztEk8+V59hge3hVdyBKAtUB73uXgOaLWzKCQ@mail.gmail.com","threadId":"33481","inReplyTo":"CAG4Fb8ekKSAiLGf_hCuLiwznCe=JOQmjS3q2-9=YeEmMaCYUNQ@mail.gmail.com","subject":"Re: git p4 submit failing","fromName":"Christopher Yee Mon","fromEmail":"christopher.yeemon@gmail.com","sentAt":"2013-04-18T16:24:42Z","receivedAt":"2013-04-18T16:24:42Z","isPatch":false,"sender":{"key":"christopher.yeemon@gmail.com","avatar":null},"body":"The issue is caused by the line endings. I retested the problem with a\ndifferent file and in this case, the error is caused by the line\nendings of the file checked out in the perforce workspace being\nwin-style crlf, and the line endings of the file in the git repo being\nunix style lf. (In this scenario, I took out the .gitattributes,\ncore.autocrlf was set to false and LineEnd was set to share)\n\nIn this case, I checked out the file in perforce, ran dos2unix against\nit, and submitted that, then ran git p4 submit and it worked.\n\nI noticed that the error is caused by the git apply failing in the def\napplyCommit(self, id) function at lines 1296-1305.\n\n        diffcmd = \"git format-patch -k --stdout \\\"%s^\\\"..\\\"%s\\\"\" % (id, id)\n        patchcmd = diffcmd + \" | git apply \"\n        tryPatchCmd = patchcmd + \"--check -\"\n        applyPatchCmd = patchcmd + \"--check --apply -\"\n        patch_succeeded = True\n\n        if os.system(tryPatchCmd) != 0:\n            fixed_rcs_keywords = False\n            patch_succeeded = False\n            print \"Unfortunately applying the change failed!\"\n\nSo most likely in git apply command, it can't find the changes because\nof the line endings being different between them. I couldn't find a\nparameter that would magically make it work. When I added --verbose to\ngit apply the output only says:\nerror: while searching for:\n<and then the first lines of the first diff>\n\nHello Simon,\n\nI have CCed you to alert you to the possible bug. Any assistance would\nbe appreciated.\n\n\nOn Sat, Apr 13, 2013 at 5:09 PM, Christopher Yee Mon\n<christopher.yeemon@gmail.com> wrote:\n> Yes this is the case.\n>\n> Many of the files have crlf endings.\n>\n> core.autocrlf was recently set to input. I can't remember the timeline\n> exactly though, but in addition to this, I have a .gitattributes file\n> with the default set to text=auto (* text=auto) and the php files set\n> to text eol=lf (*.php text eol=lf) Also my perforce workspace's\n> LineEnd setting is set to Share.\n>\n> I've experienced the behavior in both .php and .xml files though\n>\n> Before all of this started I had core.autocrlf set to false, and no\n> .gitattributes file and perforce workspace's LineEnd was set to the\n> default, but I got a conflict where the only difference was the line\n> endings, so I changed things to the way they are now.\n>\n> Any recommendations? Should I change everything back the way it was?\n>\n> On Sat, Apr 13, 2013 at 5:51 PM, Pete Wyckoff <pw@padd.com> wrote:\n>> luke@diamand.org wrote on Thu, 11 Apr 2013 21:19 +0100:\n>>> Just a thought, but check the files that are failing to see if they've\n>>> got RCS keywords in them ($Id$, $File$, $Date$, etc). These cause all\n>>> sorts of nasty problems.\n>>>\n>>> That's assuming it's definitely not a CRLF line ending problem on Windows.\n>>\n>> I had recently debugged a similar-looking problem\n>> where core.autocrlf was set to \"input\".\n>>\n>> Christopher, if you have this set and/or the .xml files\n>> have ^M (CRLF) line endings, please let us know.\n>>\n>>                 -- Pete\n>>\n>>>\n>>> On Thu, Apr 11, 2013 at 8:01 PM, Christopher Yee Mon\n>>> <christopher.yeemon@gmail.com> wrote:\n>>> > I tried running git p4 submit on a repo that I've been running as an\n>>> > interim bridge between git and perforce. Multiple people are using the\n>>> > repo as a remote and its being periodically submitted back to\n>>> > perforce.\n>>> >\n>>> > It's been working mostly fine. Then one day out of the blue I get this\n>>> > error. I can no longer push any git commits to perforce. (This is from\n>>> > the remote repo which I am pushing back to perforce)\n>>> >\n>>> > user@hostname:~/Source/code$ git p4 submit -M --export-labels\n>>> > Perforce checkout for depot path //depot/perforce/workspace/ located\n>>> > at /home/user/Source/git-p4-area/perforce/workspace/\n>>> > Synchronizing p4 checkout...\n>>> > ... - file(s) up-to-date.\n>>> > Applying ffa390f comments in config xml files\n>>> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n>>> > //depot/perforce/workspace/sub/folder/structure/second.xml#3 - opened for edit\n>>> > //depot/perforce/workspace/sub/folder/structure/third.xml#3 - opened for edit\n>>> > //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - opened for edit\n>>> > //depot/perforce/workspace/sub/folder/structure/fifth.xml#1 - opened for edit\n>>> > error: patch failed: sub/folder/structure/first.xml:1\n>>> > error: sub/folder/structure/first.xml: patch does not apply\n>>> > error: patch failed: sub/folder/structure/second.xml:1\n>>> > error: sub/folder/structure/second.xml: patch does not apply\n>>> > error: patch failed: sub/folder/structure/third.xml:1\n>>> > error: sub/folder/structure/third.xml: patch does not apply\n>>> > error: patch failed: sub/folder/structure/forth.xml:1\n>>> > error: sub/folder/structure/forth.xml: patch does not apply\n>>> > error: patch failed: sub/folder/structure/fifth.xml:1\n>>> > error: sub/folder/structure/fifth.xml: patch does not apply\n>>> > Unfortunately applying the change failed!\n>>> > //depot/perforce/workspace/sub/folder/structure/first.xml#1 - was edit, reverted\n>>> > //depot/perforce/workspace/sub/folder/structure/second.xml#3 - was\n>>> > edit, reverted\n>>> > //depot/perforce/workspace/sub/folder/structure/third.xml#3 - was edit, reverted\n>>> > //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - was edit, reverted\n>>> > //depot/perforce/workspace/sub/folder/structure/fifth.xml#3 - was edit, reverted\n>>> > No commits applied.\n>>> >\n>>> > I thought it could be the .gitattributes setting that I had which was\n>>> > this at the time was this:\n>>> >\n>>> > * text eol=lf\n>>> >\n>>> > My global core.autocrlf setting was also false.\n>>> >\n>>> > So I remade a new remote repo, and changed core.autocrlf to input and\n>>> > changed .gitattributes to this\n>>> >\n>>> > * text=auto\n>>> >\n>>> > *.php text eol=lf\n>>> > *.pl text eol=lf\n>>> > *.pm text eol=lf\n>>> > *.sh text eol=lf\n>>> >\n>>> > *.vbs text eol=crlf\n>>> > *.bat text eol=crlf\n>>> > *.ps1 text eol=crlf\n>>> >\n>>> > *.bdb binary\n>>> > *.mtr binary\n>>> >\n>>> > Then I started to realize that it could just be the files in the\n>>> > initial commit that are suspect, because when i made edits to other\n>>> > files in the repo then tried to push them back with git p4 submit,\n>>> > those files submitted successfully  But the files in the commit where\n>>> > I initially got the failure still give me this problem.\n>>> >\n>>> > Here's what it looks like when I retested with a fresh git repo cloned\n>>> > from perforce with git p4 clone and tried to do the git p4 submit with\n>>> > verbose turned on on only one of the suspecting files\n>>> >\n>>> > user@hostname:/code$ git p4 submit -M --export-labels --verbose\n>>> > Reading pipe: git name-rev HEAD\n>>> > Reading pipe: ['git', 'config', 'git-p4.allowSubmit']\n>>> > Reading pipe: git rev-parse --symbolic --remotes\n>>> > Reading pipe: git rev-parse p4/master\n>>> > Reading pipe: git cat-file commit 0457c7589ea679dcc0c9114b34f8f30bc2ee08cf\n>>> > Reading pipe: git cat-file commit HEAD~0\n>>> > Reading pipe: git cat-file commit HEAD~1\n>>> > Reading pipe: ['git', 'config', 'git-p4.conflict']\n>>> > Origin branch is remotes/p4/master\n>>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.useclientspec']\n>>> > Opening pipe: ['p4', '-G', 'where', '//depot/perforce/workspace/...']\n>>> > Perforce checkout for depot path //depot/perforce/workspace/ located\n>>> > at /home/user/Source/git-p4-area/perforce/workspace/\n>>> > Synchronizing p4 checkout...\n>>> > ... - file(s) up-to-date.\n>>> > Opening pipe: p4 -G opened ...\n>>> > Reading pipe: ['git', 'rev-list', '--no-merges', 'remotes/p4/master..master']\n>>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.skipUserNameCheck']\n>>> > Reading pipe: ['git', 'config', 'git-p4.detectCopies']\n>>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.detectCopiesHarder']\n>>> > Reading pipe: ['git', 'show', '-s', '--format=format:%h %s',\n>>> > 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\n>>> > Applying ef3b95f making test change\n>>> > Opening pipe: p4 -G users\n>>> > Reading pipe: ['git', 'log', '--max-count=1', '--format=%ae',\n>>> > 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\n>>> > Reading pipe: git diff-tree -r -M\n>>> > \"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e^\"\n>>> > \"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e\"\n>>> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n>>> > <stdin>:17: trailing whitespace.\n>>> > <!-- comment line 1 -->\n>>> > <stdin>:18: trailing whitespace.\n>>> > <!-- comment line 2 -->\n>>> > <stdin>:19: trailing whitespace.\n>>> > <!-- comment line 3 -->\n>>> > error: patch failed: sub/folder/structure/first.xml:1\n>>> > error: sub/folder/structure/first.xml: patch does not apply\n>>> > Unfortunately applying the change failed!\n>>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.attemptRCSCleanup']\n>>> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - was edit, reverted\n>>> > No commits applied.\n>>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.exportLabels']\n>>> > Opening pipe: ['p4', '-G', 'labels', '//depot/ipstor.maple/automation/...']\n>>> > Reading pipe: ['git', 'tag']\n>>> > Reading pipe: ['git', 'config', 'git-p4.labelExportRegexp']\n>>> >\n>>> > In any case, I'm starting to think it could be a legitimate bug, which\n>>> > is why I am submitting it here. Does anyone have any ideas for\n>>> > suggestions on diagnosing what could be wrong?\n>>> > --\n>>> > To unsubscribe from this list: send the line \"unsubscribe git\" in\n>>> > the body of a message to majordomo@vger.kernel.org\n>>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>>> --\n>>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>>> the body of a message to majordomo@vger.kernel.org\n>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>>>\n"},{"id":"214784","messageId":"20130418234328.GA9048@padd.com","threadId":"33481","inReplyTo":"CAG4Fb8cxdCGvzAztEk8+V59hge3hVdyBKAtUB73uXgOaLWzKCQ@mail.gmail.com","subject":"Re: git p4 submit failing","fromName":"Pete Wyckoff","fromEmail":"pw@padd.com","sentAt":"2013-04-18T23:43:28Z","receivedAt":"2013-04-18T23:43:28Z","isPatch":false,"sender":{"key":"pw@padd.com","avatar":null},"body":"christopher.yeemon@gmail.com wrote on Thu, 18 Apr 2013 11:24 -0500:\n> The issue is caused by the line endings. I retested the problem with a\n> different file and in this case, the error is caused by the line\n> endings of the file checked out in the perforce workspace being\n> win-style crlf, and the line endings of the file in the git repo being\n> unix style lf. (In this scenario, I took out the .gitattributes,\n> core.autocrlf was set to false and LineEnd was set to share)\n> \n> In this case, I checked out the file in perforce, ran dos2unix against\n> it, and submitted that, then ran git p4 submit and it worked.\n> \n> I noticed that the error is caused by the git apply failing in the def\n> applyCommit(self, id) function at lines 1296-1305.\n> \n>         diffcmd = \"git format-patch -k --stdout \\\"%s^\\\"..\\\"%s\\\"\" % (id, id)\n>         patchcmd = diffcmd + \" | git apply \"\n>         tryPatchCmd = patchcmd + \"--check -\"\n>         applyPatchCmd = patchcmd + \"--check --apply -\"\n>         patch_succeeded = True\n> \n>         if os.system(tryPatchCmd) != 0:\n>             fixed_rcs_keywords = False\n>             patch_succeeded = False\n>             print \"Unfortunately applying the change failed!\"\n> \n> So most likely in git apply command, it can't find the changes because\n> of the line endings being different between them. I couldn't find a\n> parameter that would magically make it work. When I added --verbose to\n> git apply the output only says:\n> error: while searching for:\n> <and then the first lines of the first diff>\n\nThat seems like exactly the correct diagnosis of the problem.\nWhat to do about it, I'm not so sure.\n\nWe could suggest that people use the same line-ending conventions\nin both git and p4 land.  This is easy if they are both lf.  But,\nif crlf is preferred, do you know how to configure git to use\ncrlf line endings?  Does that fix it?  There's also the config\nsetting \"apply.ignorewhitespace\"; not sure if that would allow\nthe apply step to apply an lf-ending patch to the crlf-ending p4\nworkspace.\n\n\t\t-- Pete\n\n> Hello Simon,\n> \n> I have CCed you to alert you to the possible bug. Any assistance would\n> be appreciated.\n> \n> \n> On Sat, Apr 13, 2013 at 5:09 PM, Christopher Yee Mon\n> <christopher.yeemon@gmail.com> wrote:\n> > Yes this is the case.\n> >\n> > Many of the files have crlf endings.\n> >\n> > core.autocrlf was recently set to input. I can't remember the timeline\n> > exactly though, but in addition to this, I have a .gitattributes file\n> > with the default set to text=auto (* text=auto) and the php files set\n> > to text eol=lf (*.php text eol=lf) Also my perforce workspace's\n> > LineEnd setting is set to Share.\n> >\n> > I've experienced the behavior in both .php and .xml files though\n> >\n> > Before all of this started I had core.autocrlf set to false, and no\n> > .gitattributes file and perforce workspace's LineEnd was set to the\n> > default, but I got a conflict where the only difference was the line\n> > endings, so I changed things to the way they are now.\n> >\n> > Any recommendations? Should I change everything back the way it was?\n> >\n> > On Sat, Apr 13, 2013 at 5:51 PM, Pete Wyckoff <pw@padd.com> wrote:\n> >> luke@diamand.org wrote on Thu, 11 Apr 2013 21:19 +0100:\n> >>> Just a thought, but check the files that are failing to see if they've\n> >>> got RCS keywords in them ($Id$, $File$, $Date$, etc). These cause all\n> >>> sorts of nasty problems.\n> >>>\n> >>> That's assuming it's definitely not a CRLF line ending problem on Windows.\n> >>\n> >> I had recently debugged a similar-looking problem\n> >> where core.autocrlf was set to \"input\".\n> >>\n> >> Christopher, if you have this set and/or the .xml files\n> >> have ^M (CRLF) line endings, please let us know.\n> >>\n> >>                 -- Pete\n> >>\n> >>>\n> >>> On Thu, Apr 11, 2013 at 8:01 PM, Christopher Yee Mon\n> >>> <christopher.yeemon@gmail.com> wrote:\n> >>> > I tried running git p4 submit on a repo that I've been running as an\n> >>> > interim bridge between git and perforce. Multiple people are using the\n> >>> > repo as a remote and its being periodically submitted back to\n> >>> > perforce.\n> >>> >\n> >>> > It's been working mostly fine. Then one day out of the blue I get this\n> >>> > error. I can no longer push any git commits to perforce. (This is from\n> >>> > the remote repo which I am pushing back to perforce)\n> >>> >\n> >>> > user@hostname:~/Source/code$ git p4 submit -M --export-labels\n> >>> > Perforce checkout for depot path //depot/perforce/workspace/ located\n> >>> > at /home/user/Source/git-p4-area/perforce/workspace/\n> >>> > Synchronizing p4 checkout...\n> >>> > ... - file(s) up-to-date.\n> >>> > Applying ffa390f comments in config xml files\n> >>> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n> >>> > //depot/perforce/workspace/sub/folder/structure/second.xml#3 - opened for edit\n> >>> > //depot/perforce/workspace/sub/folder/structure/third.xml#3 - opened for edit\n> >>> > //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - opened for edit\n> >>> > //depot/perforce/workspace/sub/folder/structure/fifth.xml#1 - opened for edit\n> >>> > error: patch failed: sub/folder/structure/first.xml:1\n> >>> > error: sub/folder/structure/first.xml: patch does not apply\n> >>> > error: patch failed: sub/folder/structure/second.xml:1\n> >>> > error: sub/folder/structure/second.xml: patch does not apply\n> >>> > error: patch failed: sub/folder/structure/third.xml:1\n> >>> > error: sub/folder/structure/third.xml: patch does not apply\n> >>> > error: patch failed: sub/folder/structure/forth.xml:1\n> >>> > error: sub/folder/structure/forth.xml: patch does not apply\n> >>> > error: patch failed: sub/folder/structure/fifth.xml:1\n> >>> > error: sub/folder/structure/fifth.xml: patch does not apply\n> >>> > Unfortunately applying the change failed!\n> >>> > //depot/perforce/workspace/sub/folder/structure/first.xml#1 - was edit, reverted\n> >>> > //depot/perforce/workspace/sub/folder/structure/second.xml#3 - was\n> >>> > edit, reverted\n> >>> > //depot/perforce/workspace/sub/folder/structure/third.xml#3 - was edit, reverted\n> >>> > //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - was edit, reverted\n> >>> > //depot/perforce/workspace/sub/folder/structure/fifth.xml#3 - was edit, reverted\n> >>> > No commits applied.\n> >>> >\n> >>> > I thought it could be the .gitattributes setting that I had which was\n> >>> > this at the time was this:\n> >>> >\n> >>> > * text eol=lf\n> >>> >\n> >>> > My global core.autocrlf setting was also false.\n> >>> >\n> >>> > So I remade a new remote repo, and changed core.autocrlf to input and\n> >>> > changed .gitattributes to this\n> >>> >\n> >>> > * text=auto\n> >>> >\n> >>> > *.php text eol=lf\n> >>> > *.pl text eol=lf\n> >>> > *.pm text eol=lf\n> >>> > *.sh text eol=lf\n> >>> >\n> >>> > *.vbs text eol=crlf\n> >>> > *.bat text eol=crlf\n> >>> > *.ps1 text eol=crlf\n> >>> >\n> >>> > *.bdb binary\n> >>> > *.mtr binary\n> >>> >\n> >>> > Then I started to realize that it could just be the files in the\n> >>> > initial commit that are suspect, because when i made edits to other\n> >>> > files in the repo then tried to push them back with git p4 submit,\n> >>> > those files submitted successfully  But the files in the commit where\n> >>> > I initially got the failure still give me this problem.\n> >>> >\n> >>> > Here's what it looks like when I retested with a fresh git repo cloned\n> >>> > from perforce with git p4 clone and tried to do the git p4 submit with\n> >>> > verbose turned on on only one of the suspecting files\n> >>> >\n> >>> > user@hostname:/code$ git p4 submit -M --export-labels --verbose\n> >>> > Reading pipe: git name-rev HEAD\n> >>> > Reading pipe: ['git', 'config', 'git-p4.allowSubmit']\n> >>> > Reading pipe: git rev-parse --symbolic --remotes\n> >>> > Reading pipe: git rev-parse p4/master\n> >>> > Reading pipe: git cat-file commit 0457c7589ea679dcc0c9114b34f8f30bc2ee08cf\n> >>> > Reading pipe: git cat-file commit HEAD~0\n> >>> > Reading pipe: git cat-file commit HEAD~1\n> >>> > Reading pipe: ['git', 'config', 'git-p4.conflict']\n> >>> > Origin branch is remotes/p4/master\n> >>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.useclientspec']\n> >>> > Opening pipe: ['p4', '-G', 'where', '//depot/perforce/workspace/...']\n> >>> > Perforce checkout for depot path //depot/perforce/workspace/ located\n> >>> > at /home/user/Source/git-p4-area/perforce/workspace/\n> >>> > Synchronizing p4 checkout...\n> >>> > ... - file(s) up-to-date.\n> >>> > Opening pipe: p4 -G opened ...\n> >>> > Reading pipe: ['git', 'rev-list', '--no-merges', 'remotes/p4/master..master']\n> >>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.skipUserNameCheck']\n> >>> > Reading pipe: ['git', 'config', 'git-p4.detectCopies']\n> >>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.detectCopiesHarder']\n> >>> > Reading pipe: ['git', 'show', '-s', '--format=format:%h %s',\n> >>> > 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\n> >>> > Applying ef3b95f making test change\n> >>> > Opening pipe: p4 -G users\n> >>> > Reading pipe: ['git', 'log', '--max-count=1', '--format=%ae',\n> >>> > 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\n> >>> > Reading pipe: git diff-tree -r -M\n> >>> > \"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e^\"\n> >>> > \"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e\"\n> >>> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n> >>> > <stdin>:17: trailing whitespace.\n> >>> > <!-- comment line 1 -->\n> >>> > <stdin>:18: trailing whitespace.\n> >>> > <!-- comment line 2 -->\n> >>> > <stdin>:19: trailing whitespace.\n> >>> > <!-- comment line 3 -->\n> >>> > error: patch failed: sub/folder/structure/first.xml:1\n> >>> > error: sub/folder/structure/first.xml: patch does not apply\n> >>> > Unfortunately applying the change failed!\n> >>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.attemptRCSCleanup']\n> >>> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - was edit, reverted\n> >>> > No commits applied.\n> >>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.exportLabels']\n> >>> > Opening pipe: ['p4', '-G', 'labels', '//depot/ipstor.maple/automation/...']\n> >>> > Reading pipe: ['git', 'tag']\n> >>> > Reading pipe: ['git', 'config', 'git-p4.labelExportRegexp']\n> >>> >\n> >>> > In any case, I'm starting to think it could be a legitimate bug, which\n> >>> > is why I am submitting it here. Does anyone have any ideas for\n> >>> > suggestions on diagnosing what could be wrong?\n> >>> > --\n> >>> > To unsubscribe from this list: send the line \"unsubscribe git\" in\n> >>> > the body of a message to majordomo@vger.kernel.org\n> >>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> >>> --\n> >>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> >>> the body of a message to majordomo@vger.kernel.org\n> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> >>>\n> \n"},{"id":"216665","messageId":"CAG4Fb8fKjwQ6fLzp48js6aWnc4GJU1_nB-oiH5LOoDcoV=2XPw@mail.gmail.com","threadId":"33481","inReplyTo":"20130418234328.GA9048@padd.com","subject":"Re: git p4 submit failing","fromName":"Christopher Yee Mon","fromEmail":"christopher.yeemon@gmail.com","sentAt":"2013-05-07T22:36:59Z","receivedAt":"2013-05-07T22:36:59Z","isPatch":false,"sender":{"key":"christopher.yeemon@gmail.com","avatar":null},"body":"I reset all the files to be lf. I also forced all the windows users\nIDEs to use Unix endings. I haven't seen that error since then\n\n\nThanks for the assistance\n\nOn Thu, Apr 18, 2013 at 7:43 PM, Pete Wyckoff <pw@padd.com> wrote:\n> christopher.yeemon@gmail.com wrote on Thu, 18 Apr 2013 11:24 -0500:\n>> The issue is caused by the line endings. I retested the problem with a\n>> different file and in this case, the error is caused by the line\n>> endings of the file checked out in the perforce workspace being\n>> win-style crlf, and the line endings of the file in the git repo being\n>> unix style lf. (In this scenario, I took out the .gitattributes,\n>> core.autocrlf was set to false and LineEnd was set to share)\n>>\n>> In this case, I checked out the file in perforce, ran dos2unix against\n>> it, and submitted that, then ran git p4 submit and it worked.\n>>\n>> I noticed that the error is caused by the git apply failing in the def\n>> applyCommit(self, id) function at lines 1296-1305.\n>>\n>>         diffcmd = \"git format-patch -k --stdout \\\"%s^\\\"..\\\"%s\\\"\" % (id, id)\n>>         patchcmd = diffcmd + \" | git apply \"\n>>         tryPatchCmd = patchcmd + \"--check -\"\n>>         applyPatchCmd = patchcmd + \"--check --apply -\"\n>>         patch_succeeded = True\n>>\n>>         if os.system(tryPatchCmd) != 0:\n>>             fixed_rcs_keywords = False\n>>             patch_succeeded = False\n>>             print \"Unfortunately applying the change failed!\"\n>>\n>> So most likely in git apply command, it can't find the changes because\n>> of the line endings being different between them. I couldn't find a\n>> parameter that would magically make it work. When I added --verbose to\n>> git apply the output only says:\n>> error: while searching for:\n>> <and then the first lines of the first diff>\n>\n> That seems like exactly the correct diagnosis of the problem.\n> What to do about it, I'm not so sure.\n>\n> We could suggest that people use the same line-ending conventions\n> in both git and p4 land.  This is easy if they are both lf.  But,\n> if crlf is preferred, do you know how to configure git to use\n> crlf line endings?  Does that fix it?  There's also the config\n> setting \"apply.ignorewhitespace\"; not sure if that would allow\n> the apply step to apply an lf-ending patch to the crlf-ending p4\n> workspace.\n>\n>                 -- Pete\n>\n>> Hello Simon,\n>>\n>> I have CCed you to alert you to the possible bug. Any assistance would\n>> be appreciated.\n>>\n>>\n>> On Sat, Apr 13, 2013 at 5:09 PM, Christopher Yee Mon\n>> <christopher.yeemon@gmail.com> wrote:\n>> > Yes this is the case.\n>> >\n>> > Many of the files have crlf endings.\n>> >\n>> > core.autocrlf was recently set to input. I can't remember the timeline\n>> > exactly though, but in addition to this, I have a .gitattributes file\n>> > with the default set to text=auto (* text=auto) and the php files set\n>> > to text eol=lf (*.php text eol=lf) Also my perforce workspace's\n>> > LineEnd setting is set to Share.\n>> >\n>> > I've experienced the behavior in both .php and .xml files though\n>> >\n>> > Before all of this started I had core.autocrlf set to false, and no\n>> > .gitattributes file and perforce workspace's LineEnd was set to the\n>> > default, but I got a conflict where the only difference was the line\n>> > endings, so I changed things to the way they are now.\n>> >\n>> > Any recommendations? Should I change everything back the way it was?\n>> >\n>> > On Sat, Apr 13, 2013 at 5:51 PM, Pete Wyckoff <pw@padd.com> wrote:\n>> >> luke@diamand.org wrote on Thu, 11 Apr 2013 21:19 +0100:\n>> >>> Just a thought, but check the files that are failing to see if they've\n>> >>> got RCS keywords in them ($Id$, $File$, $Date$, etc). These cause all\n>> >>> sorts of nasty problems.\n>> >>>\n>> >>> That's assuming it's definitely not a CRLF line ending problem on Windows.\n>> >>\n>> >> I had recently debugged a similar-looking problem\n>> >> where core.autocrlf was set to \"input\".\n>> >>\n>> >> Christopher, if you have this set and/or the .xml files\n>> >> have ^M (CRLF) line endings, please let us know.\n>> >>\n>> >>                 -- Pete\n>> >>\n>> >>>\n>> >>> On Thu, Apr 11, 2013 at 8:01 PM, Christopher Yee Mon\n>> >>> <christopher.yeemon@gmail.com> wrote:\n>> >>> > I tried running git p4 submit on a repo that I've been running as an\n>> >>> > interim bridge between git and perforce. Multiple people are using the\n>> >>> > repo as a remote and its being periodically submitted back to\n>> >>> > perforce.\n>> >>> >\n>> >>> > It's been working mostly fine. Then one day out of the blue I get this\n>> >>> > error. I can no longer push any git commits to perforce. (This is from\n>> >>> > the remote repo which I am pushing back to perforce)\n>> >>> >\n>> >>> > user@hostname:~/Source/code$ git p4 submit -M --export-labels\n>> >>> > Perforce checkout for depot path //depot/perforce/workspace/ located\n>> >>> > at /home/user/Source/git-p4-area/perforce/workspace/\n>> >>> > Synchronizing p4 checkout...\n>> >>> > ... - file(s) up-to-date.\n>> >>> > Applying ffa390f comments in config xml files\n>> >>> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n>> >>> > //depot/perforce/workspace/sub/folder/structure/second.xml#3 - opened for edit\n>> >>> > //depot/perforce/workspace/sub/folder/structure/third.xml#3 - opened for edit\n>> >>> > //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - opened for edit\n>> >>> > //depot/perforce/workspace/sub/folder/structure/fifth.xml#1 - opened for edit\n>> >>> > error: patch failed: sub/folder/structure/first.xml:1\n>> >>> > error: sub/folder/structure/first.xml: patch does not apply\n>> >>> > error: patch failed: sub/folder/structure/second.xml:1\n>> >>> > error: sub/folder/structure/second.xml: patch does not apply\n>> >>> > error: patch failed: sub/folder/structure/third.xml:1\n>> >>> > error: sub/folder/structure/third.xml: patch does not apply\n>> >>> > error: patch failed: sub/folder/structure/forth.xml:1\n>> >>> > error: sub/folder/structure/forth.xml: patch does not apply\n>> >>> > error: patch failed: sub/folder/structure/fifth.xml:1\n>> >>> > error: sub/folder/structure/fifth.xml: patch does not apply\n>> >>> > Unfortunately applying the change failed!\n>> >>> > //depot/perforce/workspace/sub/folder/structure/first.xml#1 - was edit, reverted\n>> >>> > //depot/perforce/workspace/sub/folder/structure/second.xml#3 - was\n>> >>> > edit, reverted\n>> >>> > //depot/perforce/workspace/sub/folder/structure/third.xml#3 - was edit, reverted\n>> >>> > //depot/perforce/workspace/sub/folder/structure/forth.xml#3 - was edit, reverted\n>> >>> > //depot/perforce/workspace/sub/folder/structure/fifth.xml#3 - was edit, reverted\n>> >>> > No commits applied.\n>> >>> >\n>> >>> > I thought it could be the .gitattributes setting that I had which was\n>> >>> > this at the time was this:\n>> >>> >\n>> >>> > * text eol=lf\n>> >>> >\n>> >>> > My global core.autocrlf setting was also false.\n>> >>> >\n>> >>> > So I remade a new remote repo, and changed core.autocrlf to input and\n>> >>> > changed .gitattributes to this\n>> >>> >\n>> >>> > * text=auto\n>> >>> >\n>> >>> > *.php text eol=lf\n>> >>> > *.pl text eol=lf\n>> >>> > *.pm text eol=lf\n>> >>> > *.sh text eol=lf\n>> >>> >\n>> >>> > *.vbs text eol=crlf\n>> >>> > *.bat text eol=crlf\n>> >>> > *.ps1 text eol=crlf\n>> >>> >\n>> >>> > *.bdb binary\n>> >>> > *.mtr binary\n>> >>> >\n>> >>> > Then I started to realize that it could just be the files in the\n>> >>> > initial commit that are suspect, because when i made edits to other\n>> >>> > files in the repo then tried to push them back with git p4 submit,\n>> >>> > those files submitted successfully  But the files in the commit where\n>> >>> > I initially got the failure still give me this problem.\n>> >>> >\n>> >>> > Here's what it looks like when I retested with a fresh git repo cloned\n>> >>> > from perforce with git p4 clone and tried to do the git p4 submit with\n>> >>> > verbose turned on on only one of the suspecting files\n>> >>> >\n>> >>> > user@hostname:/code$ git p4 submit -M --export-labels --verbose\n>> >>> > Reading pipe: git name-rev HEAD\n>> >>> > Reading pipe: ['git', 'config', 'git-p4.allowSubmit']\n>> >>> > Reading pipe: git rev-parse --symbolic --remotes\n>> >>> > Reading pipe: git rev-parse p4/master\n>> >>> > Reading pipe: git cat-file commit 0457c7589ea679dcc0c9114b34f8f30bc2ee08cf\n>> >>> > Reading pipe: git cat-file commit HEAD~0\n>> >>> > Reading pipe: git cat-file commit HEAD~1\n>> >>> > Reading pipe: ['git', 'config', 'git-p4.conflict']\n>> >>> > Origin branch is remotes/p4/master\n>> >>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.useclientspec']\n>> >>> > Opening pipe: ['p4', '-G', 'where', '//depot/perforce/workspace/...']\n>> >>> > Perforce checkout for depot path //depot/perforce/workspace/ located\n>> >>> > at /home/user/Source/git-p4-area/perforce/workspace/\n>> >>> > Synchronizing p4 checkout...\n>> >>> > ... - file(s) up-to-date.\n>> >>> > Opening pipe: p4 -G opened ...\n>> >>> > Reading pipe: ['git', 'rev-list', '--no-merges', 'remotes/p4/master..master']\n>> >>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.skipUserNameCheck']\n>> >>> > Reading pipe: ['git', 'config', 'git-p4.detectCopies']\n>> >>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.detectCopiesHarder']\n>> >>> > Reading pipe: ['git', 'show', '-s', '--format=format:%h %s',\n>> >>> > 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\n>> >>> > Applying ef3b95f making test change\n>> >>> > Opening pipe: p4 -G users\n>> >>> > Reading pipe: ['git', 'log', '--max-count=1', '--format=%ae',\n>> >>> > 'ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e']\n>> >>> > Reading pipe: git diff-tree -r -M\n>> >>> > \"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e^\"\n>> >>> > \"ef3b95f5fec193fe2612b28e2e3b5e7f8ba9419e\"\n>> >>> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - opened for edit\n>> >>> > <stdin>:17: trailing whitespace.\n>> >>> > <!-- comment line 1 -->\n>> >>> > <stdin>:18: trailing whitespace.\n>> >>> > <!-- comment line 2 -->\n>> >>> > <stdin>:19: trailing whitespace.\n>> >>> > <!-- comment line 3 -->\n>> >>> > error: patch failed: sub/folder/structure/first.xml:1\n>> >>> > error: sub/folder/structure/first.xml: patch does not apply\n>> >>> > Unfortunately applying the change failed!\n>> >>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.attemptRCSCleanup']\n>> >>> > //depot/perforce/workspace/sub/folder/structure/first.xml#3 - was edit, reverted\n>> >>> > No commits applied.\n>> >>> > Reading pipe: ['git', 'config', '--bool', 'git-p4.exportLabels']\n>> >>> > Opening pipe: ['p4', '-G', 'labels', '//depot/ipstor.maple/automation/...']\n>> >>> > Reading pipe: ['git', 'tag']\n>> >>> > Reading pipe: ['git', 'config', 'git-p4.labelExportRegexp']\n>> >>> >\n>> >>> > In any case, I'm starting to think it could be a legitimate bug, which\n>> >>> > is why I am submitting it here. Does anyone have any ideas for\n>> >>> > suggestions on diagnosing what could be wrong?\n>> >>> > --\n>> >>> > To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> >>> > the body of a message to majordomo@vger.kernel.org\n>> >>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>> >>> --\n>> >>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> >>> the body of a message to majordomo@vger.kernel.org\n>> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>> >>>\n>>\n"}]}