context diff and patch

[Rich Salz]

 >I have to disagree with the sentiment that "diff -c" is extremely
 >useful.  I find it only slightly useful.
You are in the minority.  I base this on my experience as the moderator
of comp.sources.unix.

 >You might have noticed that when I post bug fixes I never do it
 >via "diff -c".  I prefer to give enough information to RELIABLY
 >patch the code.  In any context where I would trust "patch", I
 >would also trust "ed" using the output of "diff -e", which is
 >generally much less output.
Using diff -e and ed are fine, as long as you are able to (naively) assume
that nobody will add or delete a line to what you put out.  It's possible
to "make up" for this by adding enough information so that someone can sit
down and apply changes by hand, but why penalize someone with all that
extra work just because they added
	#define malloc use_my_debugging_malloc
at the start of a 500-line file?  (Arguments about the software
engineering principals behind this are canards and obscure the point.)

And, of course, people don't just apply patches, but they also browse
through them -- perhaps they've already made the fix, or they're just
cautious.  Browsing anything other than a context diff for this purpose
is a waste of time.  Which brings us to:

 >I recently generated a "diff -c -b" comparison between [Foo Rel1]
 >sources and [Foo Rel2].  The output was larger than
 >the concatenation of all the sources.  It was useful for the
 >intended purpose (browsing), but would be ludicrous for "patch"ing.
This is known and documented behavior.  Heavens, I think any reasonable
tool user would write a script to put out the lesser of the two
outputs.  Glad to see you found it useful, tho.  Was it only "slightly"
useful this time, however?   (See first paragraph.)
	/rich $alz
-- 
Please send comp.sources.unix-related mail to rsalz at uunet.uu.net.