[Top][All Lists]

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

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

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] BUG: extra diff arguments for "tla changes --diffs"]
Date: Wed, 25 Aug 2004 17:50:37 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040309)

Miles Bader wrote:
On Wed, Aug 25, 2004 at 02:12:54PM -0400, James Blackwell wrote:

Please say _why_ it's a bad idea, i.e. give an example of how someone might
be screwed by this.

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. (which is a major use of changesets). If the person who generated the changeset tests it, they'd probably only test exact patching, not inexact.

I suppose it's conceivable that there are option combinations that could
cause some problem, but I can't see that any common options (e.g.: -p [to get
function info in the hunk header], whitespace relaxation options,

Whitespace relaxation options could quite conveivably screw up inexact patching, by causing patch to perceive a match where there isn't one.

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

context-size modification options) will.  As long as you use one of the diff
formats that makes sense (unified, context -- but I think patch will even try
to apply ed-style diffs!), patch is pretty good at handling what diff throws
at it.

I think if we stick to one standard, we'll be better able to guarantee that existing tools handle it well. tla already has test cases to make sure that the diff version handles unified diffs properly. Supporting context diffs is an additional testing burden. Same for other options.

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.

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?

I'm not against *producing* non-standard changesets. I'm all for making tla's output more human-readable. I just think that they should have a file =NON-STANDARD in them, and that tla should refuse to apply them by default. If you really want to apply them, you can always delete the file, or add a commandline switch to apply-changeset.

I think a changeset should be a changeset should be a changeset. *very*
predictable and stable.

I don't see why they're any different than patch files (really, tla's
changeset stuff is just super diff + super patch).

I see changesets as another format, which perhaps diff and patch will one day support, in addition to unified diffs, context diffs, RCS diffs, ed diffs....


Aaron Bentley
Director of Technology
Panometrics, Inc.

reply via email to

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