Kevin Shanahan <kmshanah@xxxxxxxxxxxxxx> writes: > #!/bin/sh > > mkdir a b repo > echo foo > b/foo > diff -urN a b > test.diff It is *very* surprising that this issue did not come up earlier, given that we used to use GNU diff internally to generate our own diff. If you cat the test.diff file, you will see "a/foo" and "b/foo", not "/dev/null". The problem appears that GNU diff _never_ uses "--- /dev/null" or "+++ /dev/null" to indicate creation or deletion of the file, but the "traditional patch parser" builtin-apply has assumed that is what the traditional diff output from day one. Where we got that idea is mystery to me (this is Linus's code), but I suspect it is what other SCMs did. With the GNU diff output, the only way to guess it is a file creation patch is to notice that the patch has only a single hunk that inserts into -0,0 (this tests that the file is originally empty), and it is followed by a HT and the UNIX epoch (i.e. 1970-01-01 00:00:00 GMT) timestamp in localtime + offset format (the latter is a guess to tell creation from modification to a file that was originally empty). This means that we do not have a way to tell if it was a file that had UNIX epoch timestamp that was modified or if this is a creation. Having to parse the localtime + offset and compare it with UNIX epoch is already crazy, but the saddest part is that this is quite GNU diff specific right now, and I'd rather not to require the trailing HT + timestamp (which is now being written down in new POSIX) to the "traditional patch" input format. Probably a reasonable compromise is to treat a non-git patch (i.e. the ones that does not begin with "diff --git") that touches an empty file as a file creation patch, but I need to look at the code to see how much damage such a change needs to cause. If I remember collectly it wants to decide if it is a creation patch or modification patch upfront, so it may not be as trivial as it sounds. We'll see. - 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