multi-touch-dev team mailing list archive

[Chase Douglas <chase.douglas@xxxxxxxxxxxxx>]

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.

Thanks!

-- Chase