diff of added files shouldn't show /dev/null

[Martin Pool]

For added files, bzr shows a diff from /dev/null to the new file name; this is somewhat different to what "diff -Nur" and "svn diff" does. It confuses diffstat. It may be better to just diff against the same name.

For patch to correctly add or remove the file it may be necessary to show a date of the epoch?

See https://lists.ubuntu.com/archives/bazaar-ng/2006q2/011454.html

[James Henstridge (jamesh)]

From the patch man page:

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.

So in normal operation the date would need to be the epoch for patch to remove the file if it isn't being compared against /dev/null

[Martin Pool (mbp)]

From: james.henstridge

The man page for patch indicates that this it does require the
timestamp to be the epoch for it to remove the file after patching
when the diff doesn't compare to /dev/null as it does now. I added
the relevant exerpt from the patch man page to the bug report.

If dates are going to be added to the diff output, I wonder what dates
would be appropriate to display?

When comparing to a WorkingTree the answer is pretty easy: take the
date from the file on disk.

If the comparison is against a stored revision though, there are two choices:
1. the commit date for the revision in question
2. the commit date for the last revision that changed the file in the
branch's history.

Either way, a bzr.tree.Tree.get_file_mtime() method is probably needed.

James.

[James Henstridge (jamesh)]

Fix committed to bzr.dev in rev 1743