Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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;
Yes, this change makes more sense to me, but I'll defer to Johannes' opinion before submitting another patch.
Dave
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
