Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > Well, we could make the rule be that we require --unidiff-zero only if > there really is _no_ old data to verify in a hunk. No deleted lines, and > no context around it. There are two things --unidiff-zero affects, because git-apply needs to disable otherwise reasonable sanity checks it does for safety: - When we see a patch that has only one hunk, and its change consists of only deletion, we can verify and complain if the header does not say it delete the file. Not so if the patch was created without "diff -u0". The same applies for "only addition" vs. "creation of the file". - When there is no leading context in the hunk, it usually has to match only at the beginning of the file (same for "following context" vs "at the end of the file"), and we do perform this sanity check. However, "diff -u0" patch needs to bypass it, as not having any context is the norm. Because "diff -u0" is unusual, these sanity checks are disabled only when the user explicitly says --unidiff-zero when applying. > Adrian has a point in that if there are lines to be deleted, that in > itself is context, and then the strict behaviour of "git-apply" is > arguably unnecessaily strict. Not really. That is true, unless you have two identical instances of the group of lines being deleted, in which case you cannot safely tell which instance is to be removed. > That said, I do absolutely _hate_ how GNU patch will basically apply > random line noise without complaints. So git-apply is designed to be much > stricter on _so_ many levels. The thing that I personally always really > detested about GNU patch was how it would apply part of a patch, then fail > half-way, and leave the partial patch applied! > > git-apply is about a million times better than standard "patch", exactly > because it tries to make sure that what it does makes sense, and you > actually need to use explicit flags to make it do things that may be hard > to undo or slightly questionable. No question about it. - 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
