Re: rejecting patches that have an offset

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 16, 2011, 23:22 UTC
Message-ID: <7vobzpeybh.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4E49A8EA.5020507@redhat.com>

Eric Blake <eblake@redhat.com> writes:

> It would have saved me a lot of time if both 'patch' and 'git apply'
> could be taught a mode of operation where they explicitly reject a
> patch that cannot be applied without relying on an offset.

I am not sure about this. I somehow doubt you would want to make sure that the preimage your patch is to be applied must be bit-for-bit identical to what you prepared your patch for, IOW, you are using a patchfile merely as a mean to "compress" the replacement file. You would want your RPM change to tolerate some changes in the upstream and keep your patch applicable to the next version of the upstream, no?

Given a patch that is not precise and can apply to multiple places, "patch" and/or "git apply" can apply it to a place you may not have intended. It may feel like a bug if that happens to a preimage that is bit-for-bit identical to the version you prepared your patch is against, but I would rather think, instead of blaming "patch" and/or "git apply", it would be more productive to prepare a patch with larger context when you know that the preimage file you are patching has many similar looking lines, to make it _impossible_ for it to apply to places different from what you intended.