GNU patch' behavior wrt empty files is a bit more complex than that. It's
true that you can disable it all with the POSIX mode (not that anybody
ever does), but it's not an unconditional removal, I think.
It does look at the date of the destination if there is one, ie according
to the man-page:
"You can create a file by sending out a diff that compares /dev/null or
an empty file dated the Epoch (1970-01-01 00:00:00 UTC) to the file you
want to create. This only works if the file you want to create doesn’t
exist already in the target directory. Conversely, you can remove a
file by sending out a context diff that compares the file to be deleted
with an empty file dated the Epoch. The file will be removed unless
patch is conforming to POSIX and the -E or --remove-empty-files option
is not given. An easy way to generate patches that create and remove
files is to use GNU diff’s -N or --new-file option."
and no, git never did that file date thing, so git acts differently from
GNU patch in this thing (as in so many others, for that matter).
I don't think it would necessarily be wrong to try to emulate GNU patch
for the case where git is guessing at removal, though (ie for the
"traditional diff" case - for a "git diff", the removal question is
unambiguous thanks to the git extensions, of course).
That said, I'm also not personally very motivated to add yet another odd
GNU patch behavior quirk. Especially as we very much try to avoid parsing
that insane and not-well-specified date format anyway, and just ignore it.
But if somebody sends out a tested patch to add such logic, I wouldn't
think it _wrong_ either.
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
