multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

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