On 03/27/2012 12:23 PM, Daniel d'Andrada wrote: > On 27/03/12 13:38, Chase Douglas wrote: >> On 03/27/2012 06:10 AM, Daniel d'Andrada wrote: >>> I suggest only fixing coding style in the lines your commit is going >>> change anyway and not doing changes that solely fix coding style at all, >>> even if they come as a separate commit. Unless something really ugly or >>> big has happened (e.g. an entire file is using tabs instead of spaces). >> Why not? > Pollutes unnecessarily the commit history. Commits that fix coding style > will get in front of the commits that have added or modified the logic. > So you'll have to dig below coding style commits to find the real > commits containing meaningful information about the added or modified logic. > > In the end it comes to what the developers of a project value more: > having all the code with correct coding style or having uncluttered, > more meaningful, commit history. I prefer the latter.
I guess I don't feel having an uncluttered history is all that useful. All source code repository history is cluttered, no matter what you do. If you need to audit the history of a project it is always going to be a slog. I believe the state of the current trunk head is more important than the commit history, so that's why I value having code style commits. -- Chase _______________________________________________ Mailing list: https://launchpad.net/~multi-touch-dev Post to : multi-touch-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~multi-touch-dev More help : https://help.launchpad.net/ListHelp