"Paul Lathrop" <[EMAIL PROTECTED]> writes: > That was my understanding as well. Hence "in the course of normal > development" i.e. I'm making a fix and while I make that fix I do a M-x > indent-region so the code is readable, which fixes a whitespace > problem... Or I fix a typo in a comment I notice while I'm working... > > If I have to isolate those changes from my patches I'm gonna stop trying > to contribute patches, because it seems a nightmare to me to try to > isolate general development from fixing things you notice during that > development.
Certainly you're allowed to change whitespace and reindent regions of code that you're editing anyway. The point of this sort of rule is to not add unrelated whitespace changes to the same patch. In other words, not reformatting the rest of the file in the same commit as your code edit. You can of course do it as an immediately following separate commit. The reason for this rule is mostly so that you can get a meaningful history and see when a particular change was introduced. Formatting changes always cause problems for that, but at least if any formatting changes are their own change, you can skip over them and know you can keep searching backwards when using something like git blame. Otherwise, you have to carefully compare the code to see if there are semantic changes hidden in the whitespace changes. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
