This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: typos


Hi,

On Wed, Jul 03, 2013 at 09:55:14AM +0200, Veres Lajos wrote:
> On Wed, 3 Jul 2013, Ondrej Bilka wrote:
> 
> > On Wed, Jul 03, 2013 at 12:41:42AM +0200, Veres Lajos wrote:
> > > Hi,
> > >
> > > I wrote a small misspell finder/fixer script and when I have a little
> > > spare time I clean OS projects with it. (https://github.com/vlajos/misspell_fixer)
> > > I ran it on this repository:
> > > svn://gcc.gnu.org/svn/gcc/trunk
> > > The patch is around 800kb.
> > > What is the best way to handle this modifications?
> > > I mean most of the modifications are in the comments and in the
> > > documentations, but a code-review is needed anyway. The script itself
> > > isn't enough intelligent.
> > > So how could I smooth the way to land these modifications?
> 
> > I am writing similar tool, that checks more style issues.
> > I could try to integrate that.
> >
> > My idea is run this as pre-commit hook, separate comments from diff, check it with aspell and print
> > misspelings in standard output so user can filter them.
> 
> Classic spellchekers are not really efficient for finding typos in program
> sources. There are too many false positives.
> Anyway can I help somehow?
> 
> And if the script will be done you should run it for the whole
> codebase. Otherwise the issues won't be fixed until anybody touches them.
> 

perhaps you should be aware that there are people who prefer exactly
that, though the discussions so far have been about
formatting/whitespace problems only.  The reason is simpler history
browsing which such changes complicate for little gain (I personally
can cope with it but I see the point).

On the other hand, I think that this would matter much less for lines
where there are only comments.  So I'd suggest cherry-picking these
and submitting fixes in them.  If the patch is large, split it into a
number of patches for easier review.  If there are errors in
identifiers etc. I assume that needs to be handled on case by case
basis, although some related cases can certainly be dealt with
together (and it would upset history a bit so there might even be
opposition to that).

Thanks,

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]