All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.