On Tue, Jan 21, 2014 at 6:16 PM, Pete Wyckoff <p...@padd.com> wrote:
> 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 only shows up only in p4
> repositories of dubious character, so can wait for a proper
> Tested-by: Damien Gérard <dam...@iwi.me>
> Signed-off-by: Pete Wyckoff <p...@padd.com>
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