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.

  • 15
    "Breaking commit". :-)
    – Peter K.
    Jun 13, 2012 at 18:29
  • 3
    Personally I would call a commit that size a cluster f...
    – Ramhound
    Jun 14, 2012 at 12:07
  • 1
    My boss does this all the time. Check-in comment: "everything ;o)" Jun 14, 2012 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 =) Jun 17, 2012 at 19:25
  • I might say code avalanche!
    – Brian
    Jan 8, 2014 at 19:53

8 Answers 8


(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. ...

  • 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, 2012 at 23:19
  • 1
    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, 2012 at 11:16
  • This is kind of the reason I'm against history rewriting/rebasing Nov 24, 2012 at 1:25
  • @Giorgio - that's what branches are for.
    – Brian
    Jan 8, 2014 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, 2014 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).

  • 11
    A Godzilla commit! Eeeeeeeek!!! Jun 13, 2012 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, 2012 at 16:08
  • 1
    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, 2012 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! Jun 14, 2012 at 5:45
  • What if someone's name is Jerry? Jun 18, 2012 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.

  • 5
    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).
    – user
    Jun 13, 2012 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.

  • +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, 2012 at 15:45
  • The company I was at when the developer used that term was using SourceGear Vault. Jun 13, 2012 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)


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

  • 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

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.

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