On 18 Jan 2014, at 19:22, Pete Wyckoff <p...@padd.com> wrote: > dam...@iwi.me wrote on Thu, 16 Jan 2014 17:02 +0100: >> >> On 16 Jan 2014, at 15:45, Pete Wyckoff <p...@padd.com> wrote: >> >>> 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 :) >> >>> 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". > Thanks, > > -- Pete > > ----8<-------- > > From 8556ab04dd126184e26a380b7ed08998fd33debe Mon Sep 17 00:00:00 2001 > From: Pete Wyckoff <p...@padd.com> > 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 <dam...@iwi.me> > Signed-off-by: Pete Wyckoff <p...@padd.com> > --- > 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 > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
