Actually, I would suggest having commitinfo return an error and message if the being-checked-in file is not identical to the output of indent on the same file. That would indicate that it didn't have proper indentation.
Not sure if it should be an error or warning though. Probably just a warning though, as the file is bound to be reformatted again later. Warning should probably include a diff between the non-indented and indented versions, as it will be a good check for bad patches that have missing braces/etc. cause the diff will be enormous. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Russ Allbery [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 23, 2003 3:27 PM > To: [EMAIL PROTECTED] > Subject: Re: [OpenAFS-devel] coding standards proposal > > > Jim Rees <[EMAIL PROTECTED]> writes: > > > Expanding tabs is a possibility, but I'm not convinced it's > necessary. > > One of the nice things about eliminating tabs is that the first column > added by diff then doesn't ever mess up the indentation. > > > It would require changes in the way we do things. In > particular, for me > > at least, "cvs commit" would have to do the expansion, > because not all > > the code I check in comes from my editor, and my normal > sanity checks > > (cvs diff) won't catch tabs. Maybe this could be done on the cvs > > server? > > You can do a check in commitinfo and make sure there aren't > any tabs. I'm > not sure if you can untabify from there as well. > > -- > Russ Allbery ([EMAIL PROTECTED]) > <http://www.eyrie.org/~eagle/> > > _______________________________________________ > OpenAFS-devel mailing list > [EMAIL PROTECTED] > https://lists.openafs.org/mailman/listinfo/openafs-devel > _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
