From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763088AbbA3ULg (ORCPT ); Fri, 30 Jan 2015 15:11:36 -0500 Received: from pb-smtp1.int.icgroup.com ([208.72.237.35]:51802 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753706AbbA3ULe (ORCPT ); Fri, 30 Jan 2015 15:11:34 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=NI9W8WpWIGuWaFIIxZpvdCPfcFzXAfZx mXkib6Cfq10Hi/4Eid2H4wm5vH6qxNsiX7FhJ0aqrDrG0cR+WQUOlc3Y02Vz2aEd jd3LfNnxB6dAIMTqnCBIfL213jHBxRqDPADhoBENsadoZID9UXpNh2DsplrWuKVW gjS7YEa7LNY= From: Junio C Hamano To: Jeff King Cc: Git Mailing List , Josh Boyer , "Linux-Kernel\@Vger. Kernel. Org" , twaugh@redhat.com, Linus Torvalds Subject: Re: [PATCH] apply: refuse touching a file beyond symlink References: <20150130181153.GA25513@peff.net> Date: Fri, 30 Jan 2015 12:11:30 -0800 In-Reply-To: (Junio C. Hamano's message of "Fri, 30 Jan 2015 11:48:14 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 2ECA46C0-A8BC-11E4-ADBA-7BA29F42C9D4-77302942!pb-smtp1.pobox.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Junio C Hamano writes: > Jeff King writes: > >>> + if (!patch->is_delete && path_is_beyond_symlink(patch->new_name)) >>> + return error(_("affected file '%s' is beyond a symbolic link"), >>> + patch->new_name); >> >> Why does this not kick in when deleting a file? If it is not OK to >> add across a symlink, why is it OK to delete? > > Hmph, adding > > if (patch->is_delete && path_is_beyond_symlink(patch->old_name)) > return error(_("deleted file '%s' is beyond a symlink"), > patch->old_name); > > seems to break t4114.11, which wants to apply this patch to a tree > that does not have a symbolic link but a directory at 'foo/'. > > diff --git a/foo b/foo > new file mode 120000 > index 0000000..ba0e162 > --- /dev/null > +++ b/foo > @@ -0,0 +1 @@ > +bar > \ No newline at end of file > diff --git a/foo/baz b/foo/baz > deleted file mode 100644 > index 682c76b..0000000 > --- a/foo/baz > +++ /dev/null > @@ -1 +0,0 @@ > -if only I knew I am not sure how to fix this, without completely ripping out the misguided "We should be able to concatenate outputs from multiple invocations of 'git diff' into a single file and apply the result with a single invocation of 'git apply'" change I grudgingly accepted long time ago (7a07841c (git-apply: handle a patch that touches the same path more than once better, 2008-06-27). "git diff" output is designed each patch to apply independently to the preimage to produce the postimage, and that allows patches to two files can be swapped via -Oorderfile mechanism, and also "X was created by copying from Y and Y is modified in place" will result in X with the contents of Y in the preimage (i.e. before the in-place modification of Y in the same patch) regardless of the order of X and Y in the "git diff" output. The above input used by t4114.11 expects to remove 'foo/baz' (leaving an empty directory foo as an result but we do not track directories so it can be nuked to make room if other patch in the same input wants to put something else, either a regular file or a symbolic link, there) and create a blob at 'foo', and such an input should apply regardless of the order of patches in it. The in_fn_table[] stuff broke that design completely.