> If done in two separate commits, one commit to bring the file into compliance with nxstyle, followed by a second commit to make the functional change, then it will be much easier to pinpoint where exactly the bug was introduced, because bisect will find the committer that contains only the functional change.
Exactly! On a branch in a PR and the squash, it AFTER CI and testing. -----Original Message----- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Monday, December 30, 2019 6:49 PM To: dev@nuttx.apache.org Subject: Re: Working Effectively (was Point of Order) On Mon, Dec 30, 2019 at 9:00 PM Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > > We have two options: > 1.Ensure the changed/new code comply with the coding standard > 2.Ensure the whole modified file comply with the coding standard > If the community like the 2nd option, I am fine. I can think of one disadvantage to #2: If the entire file formatting must be updated, now imagine that a bug is introduced and you bisect to locate the revision that introduced the bug. Many lines are changed, so it will be difficult to see where specifically is the change that causes the bug. If done in two separate commits, one commit to bring the file into compliance with nxstyle, followed by a second commit to make the functional change, then it will be much easier to pinpoint where exactly the bug was introduced, because bisect will find the committer that contains only the functional change. (Also it is possible that in the course of updating formatting, a mistake was made that introduces a bug. Then bisect will find the commit that changed formatting.) Nathan
