On Fri, 20 Oct 2006, Junio C Hamano wrote: > > Coding a workaround is not a big deal; the change is simple and > trivial. Yeah, I sent Junio a patch that _should_ make git accept the patches already, so technically it was easy. What irritates me personally about the new format for "-u" is that - Maybe "-u" is new as far as _POSIX_ is concerned, but daamn, it's been a standard format for a hell of a long time in real life, and this was a totally gratuitous change. - The new format is very much a new "special case". Now a totally empty line means exactly the same as a line that is " \n", so we have a new special case that simply didn't use to exist - we used to be able to just always skip the first character on a line, and consider the rest of the line to be "the data". Now you can't do that any more. The fact that GNU patch has always accepted total crap patches, has always been a thorn in my side: GNU patch is simply too accepting by default if you care about the integrity of the end result (I always ran it with "-p1 --fuzz=0" just to at least fix the most egregious cases of "we'll accept anything that loks even _remotely_ likely to apply") - git-apply was being very strict with patches on purpose. The "empty line in a patch" error has triggered several time for me, and at least so far it has _not_ ever been due to a new GNU patch, but every time due to a broken mailer or somebody not being careful when editing the patch by hand. So triggering an error has been the _right_ thing to do so far - it's been a big red sign saying "somebody did something bad to this patch". so I think the new format is strictly speaking a regression. It takes away a good sanity-check, and we're stuck with having to handle old-style patches _anyway_ for the forseeable future, so we can't replace it with a new sanity check. But it does seem like we have no choice, simply because people apparently already use the broken version. Linus - 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