00__00__00
00__00__00

Reputation: 5327

consequences of committing large amount of binary files in git repository

I have just performed a merge in git. Unfortunately, due to differences in .gitignore settings between branches, a large number of large binary files has been committed and pushed after the merge.

Later, I have removed the files from the folder, committed their delete, added them to .gitignore and copied them back to the folder.

This way I restored the pre-merge situation. However, the large files created a huge commit (GBs) with super lenghty diff which also shadows the actual merge commits.

Beside polluting the history, is there any other negative consequence of such a dumb action (computationally is this gonna slow down anything)? How to cleanup this mess in terms of disk resources and clarity of the git logs?

Upvotes: 1

Views: 344

Answers (1)

Mark Adelsberger
Mark Adelsberger

Reputation: 45649

Regarding the consequences: the biggest impact would be on clone operations - which, of course, could be slow due to transferring the large amount of data. In some circumstances fetch or push could also be affected. I wouldn't expect much impact on other git operations. Most things are done locally and hashes are used where possible, so only when the content of one of the large files is actually relevant to an operation would that operation be directly affected by the size of the file.

(I suppose depending on underlying file system, operations on pack files containing the large objects could theoretically be affected, but that sounds like a stretch to me.)

The easiest way to clean up the history is with the BFG Repo Cleaner. Doing so constitutes a history rewrite, so all the usual caveats about coordinating with other repo users would apply.

Upvotes: 1

Related Questions