[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Re: BUG: extra diff arguments for "tla changes --diffs"

From: Aaron Bentley
Subject: [Gnu-arch-users] Re: BUG: extra diff arguments for "tla changes --diffs"]
Date: Thu, 26 Aug 2004 09:51:00 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040309)

Miles Bader wrote:
Aaron Bentley <address@hidden> writes:

For instance, if you alter the number of lines of context, you can screw up inexact patching.

No you don't.  Inexact patching is _always_ only approximate, and
changing the number of context lines affects this in a controlled and
predictable manner;

Disagree. Without knowing what you're merging into, you can't predict whether increasing or decreasing the number of context lines will work better. (And if you *do* know what you're merging into, you don't need inexact patching.)

note that someone who has files which are prone to
bad patch application could also produce changesets with an _increased_
number of context lines to protect against it.

An increased number of context lines can lead to more rejects, because the extreme context boundaries may not match.

And some diff options produce patches that aren't reversible, which would definitely suck.

Sure, and tla could easily refuse to use those particular options --
they're not, however, commonly used, so it seems silly to options _in general_ with t


Every additional format the tools must support makes them more complicated to write and maintain.

Sure, so make rules about the _formats_ that are allowable -- I'd be
perfectly cool with only allowing unified diffs, for instance.

Oh, I dunno. I've gotten used to context diffs now, and they can be useful, since they show the pre and post versions of the hunk. Back when I was moving from CVS to Arch, I'd have liked RCS-style diffs in my changes --diffs output. I'd be in favour of letting any arguments be supplied to patch, so long as they were only for viewing purposes.

many (arguably most) diff options simply do not have any sigificant
affect on such issue, but _are_ quite handy for controlling the contents
of changesets; such options include -p, whitespace control, # of context
lines, -I, etc.

If standard changesets can be generated using whitespace control, the nature of changesets changes. They're no longer "the difference between this tree and that tree" but "the difference between this tree and this imaginary tree based on that tree". I think it's worth thinking twice about that.

So let's flip the question around: why *should* you be able to apply a non-standard changeset? How do those advantages outweigh the loss of simplicity?

Because (1) there is no significant loss of simplicity for most options
[see above], and (2) the patches produced are usefully different.

How is applying a changeset generated with -p "usefully different"? That's exactly the kind of output-format-altering change that has no benefit for applying changesets, but consumes programming and testing resources.


Aaron Bentley
Director of Technology
Panometrics, Inc.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]