From: Pete Wyckoff <pw@padd.com>
To: Luke Diamand <luke@diamand.org>
Cc: Christopher Yee Mon <christopher.yeemon@gmail.com>,
git <git@vger.kernel.org>
Subject: Re: git p4 submit failing
Date: Sat, 13 Apr 2013 17:51:10 -0400 [thread overview]
Message-ID: <20130413215110.GA5370@padd.com> (raw)
In-Reply-To: <CAE5ih78rw1_oE2SFQFnfUSfRfDGRW0pVC7TL1qgxwdcOFbBdCw@mail.gmail.com>
luke@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.yeemon@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
> > //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@vger.kernel.org
> > 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2013-04-13 21:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-11 19:01 git p4 submit failing Christopher Yee Mon
2013-04-11 20:19 ` Luke Diamand
2013-04-13 21:51 ` Pete Wyckoff [this message]
[not found] ` <CAG4Fb8ekKSAiLGf_hCuLiwznCe=JOQmjS3q2-9=YeEmMaCYUNQ@mail.gmail.com>
2013-04-18 16:24 ` Christopher Yee Mon
2013-04-18 23:43 ` Pete Wyckoff
2013-05-07 22:36 ` Christopher Yee Mon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130413215110.GA5370@padd.com \
--to=pw@padd.com \
--cc=christopher.yeemon@gmail.com \
--cc=git@vger.kernel.org \
--cc=luke@diamand.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).