views:

91

answers:

6

I’m in the midst of preparing some SCM guidelines for our Subversion users and came across a point of contention with the team. Is there ever a valid use case for someone to make consecutive commits with identical messages?

If you take the approach that a commit message should describe the “what” and “why” of code changes it’s difficult to see a valid case for this. Looking at our history, the instances where this has happened appear to be more out of convenience than anything else and really don’t tell the story of what the code is doing.

Does anyone have any views on the legitimacy of this? Would guidelines (or even pre-commit hooks) be overzealous or is it a reasonable expectation?

Edit: let’s work with the assumption that people are already leaving good commit messages. IMHO, a single word like “updated” or “typo” does not constitute a satisfactory commit message. I would expect to see something more like “Updated colour of submit button to green” or “Fixed typo in instructional copy”. It’s very difficult just to browse a repository log and understand what’s going on in a project without drilling into individual commits if the message is a word or two.

+1  A: 

I'll do this if I'm making a related change in two different directories (which may be widely separated in the project). It's so much easier than finding a common root directory then de-selecting lots of unrelated changes or hunting for the changes I want to check in.

Greg
+5  A: 

I guess it is the kind of problem that a technical solution cannot answer. You can always find cases that either are valid and the tool will forbid or the opposite.

One example of commit message I use quite often and tells all the story:

typo

The best solution is not technical. It is social engineering. Talk to your team.

cadrian
Personally, I would class a single word comment like “typo” as insufficient. Yes, you can do a diff to understand where the typo was but it would only take another few seconds to write “Fixed typo on submit button”, for example. This significantly enhances the legibility of the change log and certainly in a team environment, someone will benefit from this down the line.
Troy Hunt
+2  A: 

Same commit message on the same source file... stinks.

Same commit message on different source files, commited consecutively: Possibly ok, like in "added additional logging"

ammoQ
+3  A: 

I usually write very high-abstraction commit messages, because I don't really see the point of telling the same story that the diff does. That sometimes results in identical consecutive commit messages.

chaos
+1  A: 

Yes. Mostly this occurs because of inadequate training in the use and purpose of commit messages. It is a good idea to look for this regularly and approach the individuals doing it to inform them of the importance of good descriptive commit messages. If people understand how to write a good commit message, then the only dups you will see will be the occasional absent-mindedness.

Michael Dillon
I have been going through the files of large projects removing warnings for several days in a row more than once. What else would you write in your commit messages than "removed warnings"?
sbi
Results of morning's work on the 3rd day of warning removal project.
Michael Dillon
Or maybe, "Removed warnings in 7 or so .c files in GUI folder, part of warnings removal project"
Michael Dillon
Think of the guy who comes along, 2 months after you leave the company, and has to go back and figure out where a certain error was introduced into the codebase. Sometimes, errors are not discovered for many months after release is done.
Michael Dillon
@Michael: That guy will simply find out that the error was introduced during an attempt to remove warnings. Whether this was part of a "7 or so files" checkin of a "warning removal project", and whether it was during the 2st day into the project of the 3rd, might be interesting from a psychological POV, but doesn't buy the poor guy who had to debug that problem anything.
sbi
A: 

I don't see why that is bad ... you can't everytime describe what you did ... or otherwise you'll spend most of your time describing with a lot of words things that are practically non.

Examples like:

commented here and there
typo
tidyed something ...

(examples off the top of my head ...)

So, for example, "typo" - means, that if I want to write good commit messages, I should spend in 10+ characters describing a change in one letter. Bureocracy in its finest form ...

ldigas