multi-touch-dev team mailing list archive

[Peter Hutterer <peter.hutterer@xxxxxxxxx>]

On Mon, Mar 26, 2012 at 02:09:13PM -0700, Chase Douglas wrote:
> Hi all,
> 
> 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
> previously.
> 
> I have two concerns with requiring separate commits:
> 
> * It would be nicer to always have it split out into separate commits,
> but the burden for maintaining those commits usually means people don't
> bother with them, even when it's within the same area of code. In other
> words, I would rather allow for a few format fixes mixed in code changes
> than potentially forgo format fixing contributions because of the extra
> effort involved for trivial gain.
> 
> * Git interactive rebase makes it very easy to split comment and code
> changes using "git add -p" and splitting, amending, and rebasing
> previous commits. Unfortunately, Bzr was designed with a different idea
> of how software development should be done, and does not readily allow
> for editing, amending, and rebasing previous commits. The best way to
> make it work with bzr is using bzr-pipeline, but it is not as safe as
> git rebasing (i.e. it might eat your work if you use it wrong), and it
> doesn't handle rebasing changes out of one commit and into a previous
> commit. I don't think it is practical to require separate commits for
> style changes with the current bzr tools.
> 
> If you have input to provide, please do so asap, hopefully within the
> next day.

run an automated tool across the whole code-base. that way you only get one
reproducible commit per package. After that, coding discipline and patch
review should keep you there.

Cheers,
  Peter