Committing when changing source formatting?

Is it accepted practice to commit even whe开发者_Go百科n you're just changing things like whitespace, code formatting, etc.?

Yes. If you need to do whitespace changes, doing them in a separate commit that contains only this kind of cleanup is the best practice. This avoids problems with trying to see what part of a giant diff is actual code changes, and what part is just formatting (cosmetic) changes.

That said, you should try to keep these kind of changes to a minimum, and only do it at all when it is necessary and compatible with whatever coding standards are used in your company / community / project / etc.

Yes! Yes! As a separate commit, please! (These kinds of edits tend to touch a lot of code, and people need to know if a commit/changeset/patch/whatever is there purely for reformatting reasons, with no change intended to the actual code.)

G'day,

Yes. But please do it as a dedicated commit with a message stating that you've

• changed formatting,
• run the code through a code formatter, e.g. Perltidy, with a note about the setting actually used,
• etc.

Nothing worse than having formatting changes combined with functional updates so doing a diff across versions provides a poor S/N ratio!

As an aside, I'm wondering why you're making changes to the formatting of existing code. It shouldn't have been checked in if it was poorly formatted in the first place!

There's nothing worse than working with someone who goes through changing well-formatted source for no other reason other than:

• they think braces belong on the line of the "if" statement, or
• they dislike "cuddled elses", or
• etc.
• etc.

Such religious expressions of "the one true style" usually belie a lack of coding experience and experience in working in a team.

HTH

cheers,

Yes, provided there is some consistency amongst the various repositories involved, otherwise that would make any merge that much more difficult to do, because of conflict due to formatting.
At least a separate commit helps identifying the real source of potential conflict during those future merge.

If it is not "your" code (i.e some other repo with some other formatting standard will have to merge back what you are doing), you could take advantage of the git attribute filter driver, and its smudge/clean mechanism.

^{(Source: Pro Git book: Customizing Git - Git Attributes)}

You could apply your format to the code during the smudge step, and re-apply the common format standard during the clean step.

The answers already here do a good job of explaining why it can be a problem to commit formatting changes. I think one solution would be editor support to allow one to see nicely formatted code while minimizing formatting changes when saving the file.

I've asked a related question about this in...

• Is there a text editor that will "pretty print" for display without changing the underlying text?

If any good answers come up there, viewers of this question may also be interested.