multi-touch-dev team mailing list archive
Mailing list archive
Re: Policy on formatting fixes intermixed with code changes?
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
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.