Re: [PATCH] 3-way merge with file move fails when diff.renames = copies

> If new_name that is not related at all to old_name happens to exist in the
> current tree you are applying the patch to, you can grab the contents of
> the unrelated file as the preimage and try to merge the changes in.
> 
> When running --index-info for the purpose of "am -3" (hence rebase), the
> expectation is that the tree you are applying the changes to is _similar_
> to the preimage of the change, i.e. old_name.  Shouldn't missing old_name
> be treated as a fatal condition?  new_name does not have to even exist
> because otherwise you cannot accept a patch that creates the path.
> 
> Wouldn't this be a better patch, I wonder...
> 
> builtin-apply.c |    3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git i/builtin-apply.c w/builtin-apply.c
> index 4c4d1e1..7de70e9 100644
> --- i/builtin-apply.c
> +++ w/builtin-apply.c
> @@ -2573,8 +2573,7 @@ static void build_fake_ancestor(struct patch *list, const 
> char *filename)
>         else if (get_sha1(patch->old_sha1_prefix, sha1))
>             /* git diff has no index line for mode/type changes */
>             if (!patch->lines_added && !patch->lines_deleted) {
> -                if (get_current_sha1(patch->new_name, sha1) ||
> -                    get_current_sha1(patch->old_name, sha1))
> +                if (get_current_sha1(patch->old_name, sha1))
>                     die("mode change for %s, which is not "
>                         "in current HEAD", name);
>                 sha1_ptr = sha1;