Managing aesthetic code changes in git

Question

I find that I make a lot of small changes to my source code, often things that have almost no functional effect. For example:

• Refining or correcting comments.
• Moving function definitions within a class for a more natural reading order.
• Spacing and lining up some declarations for readability.
• Collapsing something using multiple lines on to one.
• Removing an old piece of commented-out code.
• Correcting some inconsistent whitespace.

I guess I have a formidable attention to detail in my code. But the problem is I don't know what to do about these changes and they make it difficult to switch between branches etc. in git. I find myself not knowing whether to commit the minor changes, stash them, or put them in a separate branch of little tweaks and merge that in later. None those options seems ideal.

The main problem is that these sort of changes are unpredictable. If I was to commit these there would be so many commits with the message "Minor code aesthetic change.", because, the second I make such a commit I notice another similar issue. What should I do when I make a minor change, a significant change, and then another minor change? I'd like to merge the three minor changes into one commit. It's also annoying seeing files as modified in git status when the change barely warrants my attention. I know about git commit --amend but I also know that's bad practice as it makes my repo inconsistent with remotes.

Answer 1

On one hand I don't think moderately frequent minor changes do a lot of harm to anything or anyone. I always commit minor cosmetic changes right away and in our team, we have agreed that we just use the word cosmetic in our commit message and that's it.

What I wouldn't recommend is commiting cosmetics together with other changes!!

On the other hand, if it is a problem for you and you would like to change something I would suggest doing cosmetic sessions where you fix all kind of things from the list you mentioned at once. It might also be more efficient to concentrate on cosmetics only at a certain point of time. Otherwise cosmetic changes can become a procrastinational activity.

Answer 2

In git, remember that until you push (or otherwise publish) your commits, you're free to edit them as you see fit. In your example, assuming you haven't pushed your major change yet, I think you'd be completely justified in merging the two minor changes. If you're worried about polluting the main codebase then you could do your work, committing as usual, then just before pushing, edit the commits so that the minor changes are all together as the most recent commit, check to see if it's large enough to be pushed and just not push that commit (yet) if it seems too small.