multi-touch-dev team mailing list archive
Mailing list archive
Re: Policy on formatting fixes intermixed with code changes?
On 27/03/12 13:38, Chase Douglas wrote:
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.
On 03/27/2012 06:10 AM, Daniel d'Andrada wrote:
On 26/03/12 18:09, Chase Douglas wrote:
As the uTouch project is growing larger and larger, we are now starting
to hit issues where code formatting may stray from the unity style
guidelines. When we develop changes, we might see incorrect style in
surrounding code. Should we have a policy that requires code format
fixes to be contained within separate commits? This has come up as an
issue in a recent merge proposal, and we haven't really discussed it
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).
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.