On Wed, Feb 27, 2002 at 01:23:17PM -0800, Andy Ross wrote: > Tony Peden wrote: > > Andy Ross wrote: > > > + They're more human readable. Inevitably, you're going to be doing a > > > diff between revisions to see what's changed anyway. This just give > > > it to you up front. If you want to look at more surrounding code, > > > you certainly can, but everyone starts with the diff anyway. > > > > Hardly. A side by side diff program such as gtkdiff or xxdiff (no > > doubt emacs has such a feature as well) is human readable. You have > > obviously taken the time to learn how to read a patch and become > > comfortable with it, but I can't imagine they were ever *meant* to be > > human readable. > > I don't quite not how to respond here, except to point out that simply > isn't the case. The "diff" program was always meant to be human > readable from the very beginning. And it's gotten more so over time, > witness the "unified" vs. "traditional" format -- the whole purpose > there was readability. > > I mean, rather than spout, try to think of a format for this problem > that would be any more readable. Diff is easy, diff is obvious: here > are some lines that used to be there and are gone, they have a "-" in > front to indicate subtraction. Here are some lines that have been > added, they have a "+" prepended. Around them are some context lines > with no prefix to show you where you are. I mean, how much simpler > can it get? [The above describes "unified" diff format -- traditional > format used a ">" instead of "+" and "<" instead of "-", and provided > no context lines, making both reading and automated merging harder]
I'll certainly agree that the patch format is a good way to represent the changes between two files -- but not to the extent that it is good at communicating that information to humans. The simple fact is that humans looking at it have to spend time decoding it first, where as a side by side diff (yes, you're right, behind the scenes it's just diffing) presents a much more digestable view. Maybe I'm just simpleminded, but I instantly understand what a big blob of color on one side and a big hole on the other side or a line of color all the way across means. > > Your response indicates to me that what you really want isn't a file > format at all, but a GUI viewer for the file changes. You realize the > gtxdiff, xxdiff and emerge (the emacs tool you posit) work *natively* > with patchfiles, right? I mean, that's what they do -- display file > diffs for the user. There's absolutely no reason you can't continue > to use these tools with patches; and in fact I'll bet money that > feeding them patches is *easier* than whole files. Of course they do, and that's just fine. They can be a black box, as far as I concerned -- I don't need or want to know how the changes are represented. I want to know what the changes are. > > Quite honestly, Tony, I think you've fallen prey to the "patch phobia" > that I talked about. It's not nearly (I mean, not even close, not > hardly, just *not*) so difficult or intractable a format as you think > it is. The /usr/bin/patch program (and not the diff file format) is a > little goofy sometimes, but the format is as simple as they come. > > Andy > > -- > Andrew J. Ross NextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > _______________________________________________ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
