3 ms·
The real issue is that in practice it is often difficult to separate these two changes. You may correct code in one place which requires correcting code elsewhe
by ranman 13y ago
The real issue is that in practice it is often difficult to separate these two changes. You may correct code in one place which requires correcting code elsewhere in a cascading effect. If you limit your correction to just one area (in a single commit) then you introduce the possibility of breaking the build. The other issue is that if you fix all the whitespace stuff first you may find the owners are not willing to pull in your commit for various reasons. I often find in open source the smaller the change the more likely it is to be merged. It's a complicated area and unfortunately often the "two different commits" strategy doesn't encompass the full complexity.
Oh and another cool feature is worddiffs for when you're editing text.
- fletchowns 13y agoThe real issue is that in practice it is often difficult to separate these two changes. ??? No it's not
- r0muald 13y agoWhitespace changes in an open source project are the kind of thing that depends on the code style enforced at the project level - certainly not something you would submit as a newcomer. Do you happen to have an example of what you're explaining here?
- Osiris 13y agoMy editor is setup to automatically trim trailing spaces. When I edit files from other devs in the group, it's not uncommon for my commits to have whitespace removal in addition to code changes. I really don't think that's a big deal. Now doing a code format to tweak indenting and brace positioning, etc., that should definitely be put into a separate commit.