Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Sometimes when we check the commit history of a software, we may see that there are a few commits that are really BIG - they may change 10 or 20 files with hundreds of changed source code lines (delta). I remember that there is a commonly used term for such BIG commit but I can't recall exactly what that term is. Can anyone help me? What is the term that programmers usually use to refer to such BIG and giant commit?

BTW, is committing a lot of changes all together a good practice?

UPDATE: thank you guys for the inspiring discussion! But I think "code bomb" is the term that I'm looking for.

share|improve this question
"Breaking commit". :-) –  Peter K. Jun 13 '12 at 18:29
Personally I would call a commit that size a cluster f... –  Ramhound Jun 14 '12 at 12:07
My boss does this all the time. Check-in comment: "everything ;o)" –  MetalMikester Jun 14 '12 at 12:11
+1 for the question because I love every answer so far, and have suffered through having committed at least one of the sins at least once in my career and want others to not do that =) –  Patrick Hughes Jun 17 '12 at 19:25
I might say code avalanche! –  Brian Jan 8 at 19:53

8 Answers 8

up vote 47 down vote accepted

(1) Ben Collins-Sussman: "... "code bombs". That is, what do you do when somebody shows up to an open source project with a gigantic new feature that took months to write? Who has the time to review thousands of lines of code? ..."

(2) Dan Fabulich: "The Code Bomb, or: The Newbie with Big Ideas ... A code bomb is a patch that's so large that no one can review it."

(3) Google Summer of Code: Guidelines: "Commit early, commit often ... Please do not work the whole day and then push everything out in a single code bomb. Instead, every commit should be self-contained to one task only which should be summarized in the log message."

(4) Jeff Atwood: "code-bombs ... Rule #30: Don't go dark. ...

share|improve this answer
link 2 and 4 directly link and quote link 1. Nothing wrong with the concept spreading, but it's a bit less relevant. I like the term, but doesn't seem like it caught up that much though. –  haylem Jun 14 '12 at 23:19
What if the commited code is new code that is quite isolated from the rest of the project? In this case I think that a single big commit of (almost) finished and cleaned-up code is better than many small commits which force people to review (1) intermediate bug fixes, (2) refactoring like class renaming and so on, (3) preliminary code that is eventually going to be deleted. Just my 2 cents. –  Giorgio Jun 17 '12 at 11:16
This is kind of the reason I'm against history rewriting/rebasing –  dukeofgaming Nov 24 '12 at 1:25
@Giorgio - that's what branches are for. –  Brian Jan 8 at 19:53
@Brian: Yes, that's a possibility. In this case you have a big commit on the main branch when you merge the functionality you have developed on the branch. –  Giorgio Jan 8 at 22:03

We probably call it a bad commit. :)

Bad Practice

And yes, that would generally be considered bad practice, as it has the negative effects of:

  • making it difficult to review,
  • making it difficult to grasp easily and quickly the commit's original intent,
  • making it difficult to see how it impacted the code to explicitly fix or address an issue,
  • making it difficult to know if the commit's size is due to noise of other possibly unrelated changes ot not (e.g. small cleanups or other tasks) .

Acceptable Cases

However, you can have cases where large commits are perfectly acceptable. For instance:

  • when merging across branches,
  • when adding new sources from another non-versioned codebase,
  • when replacing a large feature in-place (though you should rather do that in a branch, with smaller commits addressing different parts of the change, and then merge the whole thing back, so you can have a better window on the incremental development of the feature and the problems that may have been encountered along the way),
  • when refactoring an API impacting many descendent and consumer classes.

So, whenever possible, prefer "surgical strike"-types of commits (and link them to task IDs in your issue tracker!). If you have a valid reason, go ahead.

Apart from that, I actually don't know and don't think I ever heard a special name for a large commit. A monster-commit? A fat-commit?

Update: David Cary's answer links to notable IT actors using the term "code-bomb" (most importantly, Collins-Sussman, original creator of Subversion). Like that (though so far I can't say I heard if often).

share|improve this answer
A Godzilla commit! Eeeeeeeek!!! –  Péter Török Jun 13 '12 at 15:52
@PéterTörök: Liking it. Let's make it a trend. Other options: a whale commit, a Gargantuan commit, or a quite simply a BigFatCommit. –  haylem Jun 13 '12 at 16:08
Yeah, either "bad" or "late". If there's no name for it in your company, name it after the developer in question. "Hey new guy, don't do a Jerry! Commit early and commit often." –  chooban Jun 13 '12 at 17:37
Don't do a Jerry, that's a useful approach! Also massive-commit can source from stressed developers not beleiving in or understand the use of versioning. Check the knowledge! –  Independent Jun 14 '12 at 5:45
What if someone's name is Jerry? –  Loïc Faure-Lacroix Jun 18 '12 at 8:39

BTW, is committing a lot of changes all together a good practice?

Well, it's not good practice to hold onto changes for a long time, and implement a variety of features and bug fixes, and then commit them, which is one way a big commit could happen.

Another way this could happen is if a refactoring changes the signature of a widely-used function, and then all those have to be changed. This isn't necessarily bad, and I wouldn't want developers to refrain from cleaning up the code for fear of crossing some threshold.

So, there's more to it than just looking at the number of files touched in a commit.

share|improve this answer
This. What really matters is not the number of files changed, or the number of lines changed, but the scope of the changes. If you can succintly and accurately describe the set of changes in a short commit message that doesn't leave anything out, the physical change count is relatively inconsequential. Not unimportant, but myself, I'd rather have one big commit that keeps the code buildable than a set of commits where only some of them result in a source code tree that will build (c.f. method signature changes). –  Michael Kjörling Jun 13 '12 at 20:05

The term I've heard is "chunky check-ins". And I'm not a fan of them. I like smaller commits that ensure nothing else is broken at reasonable step in a project. The big commit is generally fraught with issues that reverberate for some time out of when that happens.

share|improve this answer
+1 as i didn't remember that at the time (though I don't think that's a generic term, or I'm unaware of it), but I've heard the word "chunk" used specifically by mercurial in relation to an extension allowing to submit a large commits with different chunks of data, but apart from that I don't think I ever heard that term for commits in general. –  haylem Jun 13 '12 at 15:45
The company I was at when the developer used that term was using SourceGear Vault. –  Jesse C. Slicer Jun 13 '12 at 15:59

I call it "typical SVN commit" or "tomorrow is release day commit"

As much as I love SVN, I'm just turned off by the fact that I can't do local commits.

EDIT: they usually have the words "stuff" and "beer" in the commit message.

EDIT AGAIN: Committing a lot of changes, while not necessarily a bad practice, should be as much as possible avoided. I find it easier to review a revision/commit that's short and concise. (paired with a well-written commit message, see my previous edit for a bad example)

share|improve this answer

A "hot steaming lump of code". :-)

share|improve this answer
  • initial commit - the project that was not under revision control thrown into SVN
  • refactoring - the architect has brilliant idea about changing class names from/to Smurf Naming Convention or changed the root of package hierarchy
  • code format - the architect have decided to change the code indent from 4 to 3 spaces or change line endings from Unix to Windows (or revert)
  • Friday commit - Joe is always commiting his whole week work on Fridays at 16:30
  • uuups commit - Ted has by mistake deleted root directory, commited that, and now he pumps once again the whole file hierarchy into SVN
share|improve this answer

Usually many people tend to make big commit using centralized VCS, especially the server enforce good commit policy. That is the commit must pass all tests and the tests take longer time (longer than a few seconds). So developers do not want to wait so long to commit multiple times and break down changes into multiple small commits.

And developers that are green to VCS may forget to break down changes into multiple small commits. They only remember to commit when they release the program to QA team. Worse still, to avoid others to see buggy code, they do not commit before successfully passed QA testing. Last, they did not realize that they have committed output binaries, temporary files and linker output, which really produce "big" commit.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.