Re: Why doesn't git-apply remove empty file

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 13 Aug 2008, René Scharfe wrote:
> 
> I bet you are using GNU patch.  It removes files that are empty after
> patching and you need to specify --posix to make it keep empty files.

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