On Thu, Nov 15, 2018 at 5:12 PM Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
>
> On 11/15/18 6:40 AM, Jan Tulak wrote:
> > On Wed, Nov 14, 2018 at 9:36 PM Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
...
> >> 3) This creates /many/ more > 80 char lines. Per:
> >>
> >> # for F in */*.[ch]; do expand $F | grep '.\{81\}'; done
> >>
> >> the codebase goes from 794 such lines to 1806. IOWs, some of the "missing"
> >> whitespace may have been intentional, to stay under 80 cols. New lines
> >> vs. compressed lines is a judgement call, I guess. Bleah.
> >>
> >> So... sorry about that, but if the goal is to format better, let's be
> >> sure to keep observing other basic rules like "< 80 cols"
> >
> > Yeah. I'm not sure there is an easy way to automate that...
>
> Well, I think that's kind of the point here. Do your automated replacement,
> but then manually inspect the result - you can look for 80col problems with
> the example above. Then manually fix up as needed. Then proceed to the next
> patch.
>
> Reviewers will need to look at the changes closely nyway, so you may as well
> do it before submission. ;)
>
It's about all the rebase conflicts that arises after any change in
previous patches. If it was a thing I write once, then so be it. But
if I have to rewrite it again after any change in one of the previous
patches, well, that doesn't scale. :-) But I hope I can solve this
somehow.
Thanks,
Jan
--
Jan Tulak
