[Mulgara-dev] committing guidelines

[Andrae Muys]

On 28/03/2008, at 4:51 PM, 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.
> 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.  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.
>
> 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).  :-)


On the other hand it is possible to cleanup a file, and selectively  
commit it, _before_ you make your changes.  That may be the best of  
both worlds, isolating formatting changes without requiring you to  
extract them from substantive code updates.

Andrae

-- 
Andrae Muys
andrae at netymon.com
Senior RDF/SemanticWeb Consultant
Netymon Pty Ltd