[merge] Enhancement to also use the external diff tool for new and deleted files.
Aaron Bentley
aaron at aaronbentley.com
Tue Sep 16 15:20:04 BST 2008
-----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-----
More information about the bazaar
mailing list