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

[David Ingamells]

Thanks for your patience, Aaron, now to try it further ...

Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Ingamells wrote:
>   
>> Aaron Bentley wrote:
>> Is the external diff tool used to create patches?
>>     
>
> By default, we use our internal diff implementation.  But when "--using
> diff" is supplied, or when --diff-options is supplied, we use an
> external diff tool.
>
>   
>> I was under the
>> impression that "bzr send" did that (or "bzr diff -p1"
>>     
>
> Not sure what you mean, but "bzr send" always uses the internal diff
> implementation, and "bzr diff" uses it by default.
>
>   
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.
>> and that "bzr
>> diff --using" was for producing human friendly display for reviews.
>>     
>
> Well, it's for producing alternate outputs.  That may include colordiff
> or diff -pwu, or anything, really.
>
>   
>> If /dev/null is the 0-sized file, then how does one change the
>> modification time of it?
>>     
>
> I doubt that a normal user can change the modification time of
> /dev/null, but the function would be os.utime.
>
>   
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?

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.
>> What is the "inverse" of this?
>>     
>
> I was saying for deleted files, the "new" state is /dev/null, 0-length,
> unix epoch.  The inverse is that for created files, the "old" state is
> /dev/null, 0-length, unix epoch.
>
> Aaron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIz6uP0F+nu1YWqI0RAjO5AJwIxU6C/E7uYnaj9DzhtNwfkUIkuQCfT96g
> AU8CxS/vlANJv3dOtLrW6fY=
> =eLb6
> -----END PGP SIGNATURE-----
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20080916/3561a617/attachment.htm