We probably call it a bad commit. :)
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) .
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).