Re: git-p4: exception when cloning a perforce repository
From: Damien Gérard <hidden>
Date: 2016-06-15 22:59:42
On 18 Jan 2014, at 19:22, Pete Wyckoff [off-list ref] wrote:
damien@iwi.me wrote on Thu, 16 Jan 2014 17:02 +0100:quoted
On 16 Jan 2014, at 15:45, Pete Wyckoff [off-list ref] wrote:quoted
Oh cool, that helps a lot. P4 is just broken here, so we can get away with being a bit sloppy in git. I'll try just pretending "empty symlinks" are not in the repo. Hopefully you'll have a future commit in your p4 repo that brings back bn.h properly.Thanks ! I would love to use git instead of perforce if possible :)quoted
Still not sure about how I'll test this.I can test for you, no probleme with that.Any chance you can give this a go? I've a bigger patch in a longer series, but this should be the minimal fix. If it works, I'll ship it to Junio.
Just for info, it works but it seems there are still some issues when a git repository is present within the perforce repo : error: Invalid path 'Tools/Doc/bin/yuidoc/.git/FETCH_HEAD' error: Invalid path 'Tools/Doc/bin/yuidoc/.git/HEAD' error: Invalid path 'Tools/Doc/bin/yuidoc/.git/ORIG_HEAD’ [...] Those files have been added then removed in another commit I’ve have to make git reset —hard ‘HEAD^’ && git p4 sync to a clean staging area right after the "clone".
quoted hunk ↗ jump to hunk
Thanks, -- Pete ----8<-------- From 8556ab04dd126184e26a380b7ed08998fd33debe Mon Sep 17 00:00:00 2001 From: Pete Wyckoff <redacted> Date: Thu, 16 Jan 2014 18:34:09 -0500 Subject: [PATCH] git p4: work around p4 bug that causes empty symlinks MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Damien Gérard highlights an interesting problem. Some p4 repositories end up with symlinks that have an empty target. It is not possible to create this with current p4, but they do indeed exist. The effect in git p4 is that "p4 print" on the symlink returns an empty string, confusing the curret symlink-handling code. In p4, syncing to a change that includes such a bogus symlink creates errors: //depot/empty-symlink - updating /home/me/p4/empty-symlink rename: /home/me/p4/empty-symlink: No such file or directory and leaves no symlink. Replicate the p4 behavior by ignoring these bogus symlinks. If they are fixed in later revisions, the symlink will be replaced properly. Reported-by: Damien Gérard <redacted> Signed-off-by: Pete Wyckoff <redacted> --- git-p4.py | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)diff --git a/git-p4.py b/git-p4.py index 5ea8bb8..e798ecf 100755 --- a/git-p4.py +++ b/git-p4.py@@ -2075,7 +2075,14 @@ class P4Sync(Command, P4UserMap): # p4 print on a symlink sometimes contains "target\n"; # if it does, remove the newline data = ''.join(contents) - if data[-1] == '\n': + if not data: + # Some version of p4 allowed creating a symlink that pointed + # to nothing. This causes p4 errors when checking out such + # a change, and errors here too. Work around it by ignoring + # the bad symlink; hopefully a future change fixes it. + print "\nIgnoring empty symlink in %s" % file['depotFile'] + return + elif data[-1] == '\n': contents = [data[:-1]] else: contents = [data]-- 1.8.5.2.320.g99957e5