On Tue, Jan 06, 2015 at 02:56:58PM +0000, Joseph Myers wrote: > On Tue, 6 Jan 2015, James Greenhalgh wrote: > > > I was aiming to: > > > > * Remove outdated details of the compiler. > > * Remove long or obscure words that, while accurate, only served to > > obfuscate a simple idea. > > * Refer to similar things in a consistent fashion - in particular > > trying to keep consistent use of "insn" and "pattern". > > * Remove superflous examples, or waffling. > > * Update some K&R C and make it use GNU-style. > > > > I've split the patch to a 5-patch series, roughly covering one section > > in each. > > It would be much more reviewable if the patches were split logically - > each addressing only one of the five issues you mention above - rather > than physically.
That is rather difficult to tease out of a documentation patch without ending up with a very deep patch stack. Of course such a request is possible, but often the partial change makes little sense or improvement without rewriting an entire section, and the burden of making the intermediary changes read well makes the process of rewriting documentation exceedingly laborious. Splitting to this granularity essentially requires a per-paragraph justification. In reality, a per-paragraph justification of my changes will be easier for me to provide than a deep patch set. I'll try to find some time one evening this week to "review" my patches to give this context, if that would be acceptable. Hopefully I'll find a few more areas where the text can be improved along the way! > and "Update text." is thoroughly unhelpful as a ChangeLog entry to > explain the intent of the changes. Well, indeed, but ChangeLog entries have always been a thoroughly unhelpful "what changed" rather than "why did it change". (grep ": Update\." gcc/ChangeLog*) ! Thanks, James
