What is the term for a really BIG source code commit?

Question

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.

Answer 1

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

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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)

Answer 6

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

Answer 7

• 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

Answer 8

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.