: What about reformatting the whole file and noting in the checkin notes : "reformat only, no code changes"? (assuming an egregiously : badly-formatted file that one is working on).
objection to these types of of commits has historicly been that it may make it harder to apply patches that other people people submit or have submitted (ie: a patch in jira against trunk that hasn't been applied yet, or a patch someone makes against the 3.3 release that can no longer apply to the 3x branch because of the code reformatting, etc...) i use to agree with that as part of the general philosohy of "if it aint broke, don't fix it" ... but i think over time my definition of "broke" has changed ... code you can't read because it isn't indented consistently is (t ome) broken code. so fix away. but yes: we should at least isolate such changes. I'd much rather see these two commits: +2/-2 == fixed race condition in DocWriter +425/-410 == fixed consistent formatting in DocWriter ...then see this... +427/-412 == fixed race condition and formatting in DocWriter -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
