[Mulgara-dev] committing guidelines

[Life is hard, and then you die]

On Fri, Mar 28, 2008 at 01:51:45AM -0500, Paul Gearon wrote:
> On Fri, Mar 28, 2008 at 1:39 AM, Life is hard, and then you die <
> ronald at innovation.ch> wrote:
> 
> > May I suggest something regarding how many changes to commit together?
> > I was just looking through r718 (sorry Paul, nothing personal, just a
> > very obvious example that pushed my button) trying to figure out what
> > exactly the change was, and it was a right royal pain because about
> > 90% of the changes were whitespace/comments/general-formatting fixes
> > and only about 10% were related to the actual thing being fixed.
> >
> > I understand very well that when you're in a file fixing stuff that
> > you want to also fix all the formatting things, but I would like to
> > suggest that those two things please be pulled apart and committed
> > separately. Yes, it's a pain to go in an undo various stuff and commit
> > in multiple parts, but if we want others to be able to review the
> > changes then this is essential. IMNSHO, if things like formatting
> > fixes make up more than 10% of the changes then they should be
> > committed separately. I even go so far as to say that, e.g., if you
> > have two not directly related sets of changes a files and one set also
> > affects another file, then again split them up into two separate
> > commits.
> >
> > Anyway, that's my suggestion. Flames away...
> 
> Yes, this makes sense.  If I were reviewing it, then sure, I'd probably have
> posted the same suggestion.
> 
> My perspective is that the formatting must be changed (it regularly violates
> the coding standards we've had from the outset - sometimes in confusing
> ways). Even if it didn't have to be changed, I'd often want to do it anyway,
> as I'm often finding code that I wrote that *someone* (yes, I know who)
> reformatted incorrectly.

Completely agree. I didn't mean to imply in any way that cleaning up
the formatting isn't a good thing.

> If I put off reformatting until my changes are
> done, then it won't happen. I can't reformat before I've made the changes,
> as I often don't know that I'm about to change a class until I need to (due
> to editing another class). It makes a lot of sense from my end to do it all
> in one go.

If quite regularly end up, just before committing, going in and
reverting a whole bunch of changes, committing what's left, and then
redoing the changes and committing again. Or pulling out the
unmodified version (subversion makes this easy), selectively applying
certain changes, committing, and then committing the final stuff. Yes,
it's extra work, but it keeps the history much cleaner (for some 
reason I seem to be in a minority of folks who use the history 
regularly - maybe that's why I'm usually the only one complaining
about this on the various projects I'm involved in).

> I'll *try* to make it easier for you by splitting it up.  I won't make any
> promises though (unless I get shouted down).  :-)

Thanks. But it's not just for me (I hope), but for _anybody_ who
reviews changes.


  Cheers,

  Ronald