git p4: work around p4 bug that causes empty symlinks

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. Such broken repositories cause problems in p4 as well, even with no git involved. In p4, syncing to a change that includes a bogus symlink causes 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. In git, replicate the p4 behavior by ignoring these bad symlinks. If, in a later p4 revision, the symlink happens to point to something non-null, the symlink will be replaced properly. Add a big test for all this too. This happens to be a regression introduced by 1292df1 (git-p4: Fix occasional truncation of symlink contents., 2013-08-08) and appeared first in 1.8.5. But it shows up only in p4 repositories of dubious character, so can wait for a proper release. Tested-by: Damien Gérard <damien@iwi.me> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Pete Wyckoff committed Jan 21, 2014 at 18:16 UTC 40f846c35c504a1c2303be5dcca6db069a17b856
2 files changed +74 -1
git-p4.py
+8 -1
@@ -2075,7 +2075,14 @@ class P4Sync(Command, P4UserMap):
2075 # p4 print on a symlink sometimes contains "target\n";
2076 # if it does, remove the newline
2077 data = ''.join(contents)
2078 - if data[-1] == '\n':
2078 + if not data:
2079 + # Some version of p4 allowed creating a symlink that pointed
2080 + # to nothing. This causes p4 errors when checking out such
2081 + # a change, and errors here too. Work around it by ignoring
2082 + # the bad symlink; hopefully a future change fixes it.
2083 + print "\nIgnoring empty symlink in %s" % file['depotFile']
2084 + return
2085 + elif data[-1] == '\n':
2086 contents = [data[:-1]]
2087 else:
2088 contents = [data]
t/t9802-git-p4-filetype.sh
+66
@@ -267,6 +267,72 @@ test_expect_success SYMLINKS 'ensure p4 symlink parsed correctly' '
267 )
268 '
269
270 +test_expect_success SYMLINKS 'empty symlink target' '
271 + (
272 + # first create the file as a file
273 + cd "$cli" &&
274 + >empty-symlink &&
275 + p4 add empty-symlink &&
276 + p4 submit -d "add empty-symlink as a file"
277 + ) &&
278 + (
279 + # now change it to be a symlink to "target1"
280 + cd "$cli" &&
281 + p4 edit empty-symlink &&
282 + p4 reopen -t symlink empty-symlink &&
283 + rm empty-symlink &&
284 + ln -s target1 empty-symlink &&
285 + p4 add empty-symlink &&
286 + p4 submit -d "make empty-symlink point to target1"
287 + ) &&
288 + (
289 + # Hack the p4 depot to make the symlink point to nothing;
290 + # this should not happen in reality, but shows up
291 + # in p4 repos in the wild.
292 + #
293 + # The sed expression changes this:
294 + # @@
295 + # text
296 + # @target1
297 + # @
298 + # to this:
299 + # @@
300 + # text
301 + # @@
302 + #
303 + cd "$db/depot" &&
304 + sed "/@target1/{; s/target1/@/; n; d; }" \
305 + empty-symlink,v >empty-symlink,v.tmp &&
306 + mv empty-symlink,v.tmp empty-symlink,v
307 + ) &&
308 + (
309 + # Make sure symlink really is empty. Asking
310 + # p4 to sync here will make it generate errors.
311 + cd "$cli" &&
312 + p4 print -q //depot/empty-symlink#2 >out &&
313 + test ! -s out
314 + ) &&
315 + test_when_finished cleanup_git &&
316 +
317 + # make sure git p4 handles it without error
318 + git p4 clone --dest="$git" //depot@all &&
319 +
320 + # fix the symlink, make it point to "target2"
321 + (
322 + cd "$cli" &&
323 + p4 open empty-symlink &&
324 + rm empty-symlink &&
325 + ln -s target2 empty-symlink &&
326 + p4 submit -d "make empty-symlink point to target2"
327 + ) &&
328 + cleanup_git &&
329 + git p4 clone --dest="$git" //depot@all &&
330 + (
331 + cd "$git" &&
332 + test $(readlink empty-symlink) = target2
333 + )
334 +'
335 +
336 test_expect_success 'kill p4d' '
337 kill_p4d
338 '