Peter Samuelson wrote:
> [Mathias Weinert]
> > As the second one doesn't make it obvious that the file is missing
> > (on the first sight there is a "normal" path).
> It doesn't seem confusing to me at all. Don't all Unix users (i.e.,
> most people who know how to read udiff format) know what "/dev/null"
> > --- file1 r5 Sun Sep 9 15:40:00 2001 (original)
> > +++ () 00:00:00 1970 (empty, because file is deleted)
> > Could you please confirm that this works with your GNU patch?
> That case works, yes. However, the extra "r5" field, in the general
> case, messes up the patch -T and -Z options. Since those options are
> the only reason I can think of to bother printing timestamps, you may
> as well remove the "Sun Sep 9 15:40:00 2001" entirely.
> I'm still not convinced that "()" is a clearer magic filename than
> "/dev/null". The advantage of "/dev/null" is that you can omit the
> timestamp in _all_ cases, and I find the lack of such clutter
> refreshing when reading udiffs, especially since this usually prevents
> the --- +++ headers from wrapping past 80 columns. My own patch
> management scripts already remove timestamps from my diff headers, for
> readability, and I happen to know I'm not the only one who does this.
As already said in an earlier post IMHO the output of mailer.py is more
a textual information than a base for any kind of automatic processing.
On the other hand there seem to be several people out there who use
mailer.py's output to apply patches etc.
So why not defining an additional configuration parameter 'diff_style'
with the possible values 'human' which prints the diff labels like
suggested (may be using /dev/null for deleted paths) and 'patch' which
prints no additional information?
Two additional thoughts about this:
1. Although we would introduce two types of diff output, both of them
would work with patch if no additional flags are given with the
2. I don't mind using /dev/null for deleted paths. The only additional
argument that comes into my mind is that a Windows user will not know
anything about /dev/null.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Sep 18 15:44:34 2006