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

I don't think you should include them with other "real" changes. Doing so makes it difficult to review changes when merging branches.

Perhaps your idea of keeping these minor changes on their own branch has merits.

When I was using Perforce (with it's multiple changelists) I could keep these edits in a separate changelist until I had "sufficient" to warrant a check in. The check in would contain multiple files and each file could have multiple layout changes but no "real" changes.

Answer 2

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 3

I think you should commit these changes individually with better commit messages. Instead of 'Minor code aesthetic change.' you should write something such as 'Changed spacing of header in the X section in the X view'.

That won't hurt you in any way.

Answer 4

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.

Answer 5

I suggest keeping them separate and sticking to that so that at least the other developers can just merge them in without too much fear. :-) I have a tendency to do what you describe as well.

Another suggestion that works is to define a standardized formatting for the code and use your IDE or some other process (build/checkin) to automatically format the code on save or checkin. With that you can still have your own format locally if you are a rebel :-) but then all of the code looks the same when it is checked in.

I think git has the ability to define pre-checkin hooks, but there are also ant targets, maven plug-ins and IDE functions/plugins that will do the automatic formatting in an out-of-your-way manner.

Answer 6

You're lucky to be using git! As others have pointed, you can combine changes before you push them to the repo. This is one of the cooler differentiators of git. I can walk you though it if you work on a branch:

> git checkout dev  # branch for work
>> ... do some stuff
> git commit -am 'cosmetic only 1'
>> ... do some more stuff
> git commit -am 'cosmetic stuff I missed last time'
>> ... do some real stuff
> git commit -am 'real work'
> git checkout master && git pull && git checkout dev 
  # optional, if you repo is out of date
> git rebase --interactive master

At this point you can re-arrange your commits, and combine them together-- exactly what you want. Then finally:

> git checkout master && git merge dev && git push && git checkout dev

So the secrets are:

• git's ability to easily work on a branch
• git's convenience of checking in often
• git's ability to edit commits already in the system

To be honest, I generally don't worry about the commit log that much. I just dig through the history seldom enough to make this sort of maintenance worth the effort.

BTW I'm sure there's a way to do this if you don't work on a branch, but I don't know it. Here's a reference for working on a branch: http://osteele.com/archives/2008/05/my-git-workflow