[merge] Enhancement to also use the external diff tool for new and deleted files.

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Ingamells wrote:
> Thanks for your patience, Aaron, now to try it further ...
>> What I meant was that I thought that patches are generated only with the
>> internal diff,
>> but I think you are saying here that
>> 1) For bzr's use the internal tool is used. (and my update is irrelevant
>> for this)
>> 2) an external diff tool can also be used to create a patch file for
>> non-bzr purposes if the user wishes.
>> (Which means it won't be guaranteed to be a patch file that bzr
>> understands), and it is in
>> this context that my update fails.

Right.  I took the easy way out when I originally coded this, because I
expected different tools would need different ways of representing
deleted files.  So I just forced the internal diff.

>> You say that the requirement is that for patch to see a change as a delete,
>> the "new" file must be /dev/null and /dev/null's modification time must
>> be the UNIX
>> epoch (e.g. 1st Jan 1970). You say further that a normal user is
>> unlikely to be able to change the
>> modification time of /dev/null, which is also my impression after a few
>> small experiments.
>> e.g.
> 
>>     $ touch -m /dev/null
>>     touch: setting times of `/dev/null': Operation not permitted
> 
>> On my desktop it looks like it has the date of the last boot.
> 
>> The mod date of /dev/null is thus *never* the UNIX epoch.
>> How, then, can the requirement *ever* be true?

When diff encounters a deleted file, it generates synthetic data.  In
fact, the point of using the epoch is that it's unlikely to be true.

>> I can easily change the code to use /dev/null. [I did indeed try that
>> originally, but due
>> to an awkwardness in the original code where the paths to the files were
>> generated
>> in 2 different places it didn't work; later after I'd changed the zero
>> file generation I discovered
>> and removed that awkwardness.] However it still won't (and cannot)
>> satisfy the
>> requirements for modification date. It looks like I'm on a sure loser here.

It seems likely to me that the modification date is more important than
the file name.  I haven't tested this with 'patch', though.

The --using functionality was originally provided by a plugin called
difftools: https://code.launchpad.net/~sward-dev/bzr-difftools/trunk

My implementation doesn't have nearly the same rich functionality, but
at least it's in core.  The original had special cases for a variety of
different tools, and distinguished between per-file tools and whole-tree
tools.

So I think it's worth pursuing an implementation where diff --using is
unchanged, but your particular tool is handled better.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIz8CU0F+nu1YWqI0RAoZOAJ9B7mONMJXhlvHQABh+9jEyLXT1WgCeP1z+
N9PjmLMCh9t9p8sQe2ALHio=
=t3hu
-----END PGP SIGNATURE-----