[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: Miles Bader
Subject: [Gnu-arch-users] Re: BUG: extra diff arguments for "tla changes --diffs"]
Date: Thu, 26 Aug 2004 13:28:50 +0900

Aaron Bentley <address@hidden> writes:
>>>Its a bad idea because that opens us up to the risk that people will
>>>generate and start passing around changesets that aren't portable.
>> For instance?
> 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; 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.

> 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

> Reducing the level of standardization makes it harder to write 
> additional tools.  I want to be able to edit a changeset and remove 
> unwanted changes.  I want to be able to determine which lines a 
> changeset touches, and how the lines are renumbered afterward.  I want 
> to be able to do changeset composition, and merge two changesets into 
> one.  I even want to subtract changesets from each other.  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.  However
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.

> 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.

Suburbia: where they tear out the trees and then name streets after them.

reply via email to

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