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

[Miles Bader]

On Thu, Aug 26, 2004 at 09:51:00AM -0400, Aaron Bentley wrote:
> >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.)

What's _that_ supposed to mean?  You similarly can't predict whether the
_default_ will be any good or not -- we just accept that it will work OK most
of the time, and for `typical' source code.  Using the same assumptions,
increasing or decreasing the # of context lines tends affect patching
behavior in a fairly predictable behavior (bumping it by 1 will cause some
extra reject, but usually not a huge amount, bumping it by 30 _will_ probably
end to cause a lot more rejects).

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

Well duh.  But this is well-known and predictable behavior; someone who
changes the # of context lines does so for a reason.

> >>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
> 
> Eh?

What didn't you understand?  If option X is bad, be more picky when the user
uses option X -- but don't out-of-hand reject _all_ options just because X
exists.

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

Well fine, you can set the "restrict to viewing flag" _for those options
which warrant it_ (ed mode, etc).

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

Sure think about it.  But don't just assume that it's so dangerous.

These "diff options" are _optional_ -- most users will _not use_ them, and
those that do, do so knowingly.  I don't think that results are somehow so
horrible that extraordinary measures need to be taken to protect the user
from themselves.

> >>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"? 

Yeesh, I didn't claim that _every_ option was usefully different for
patching, just that _some_ are -- and that should be enough.

-p clearly is useful for viewing patches though, and it's not at all common
to produce changesets as both `documentation' (for patch reviewing) and for
application (after the review passes :-).

> That's exactly the kind of output-format-altering change that has no 
> benefit for applying changesets, but consumes programming and testing 
> resources.

Oh it does not.

You're grasping at strawmen.

-Miles
-- 
We have met the enemy, and he is us.  -- Pogo