On Wed, Mar 14, 2018 at 9:14 AM, Lars Schneider <larsxschneider@xxxxxxxxx> wrote: > I am using Michael's fantastic Git repo analyzer tool "git-sizer" [*] > and it detected a very large commit of 7.33 MiB in my repo (see chart > below). > > This large commit is expected. I've imported that repo from another > version control system but excluded all binary files (e.g. images) and > some 3rd party components as their history is not important [**]. I've > reintroduced these files in the head commit again. This is where the > large commit came from. > > This repo is not used in production yet but I wonder if this kind of > approach can cause trouble down the line? Are there any relevant > implication of a single large commit like this in history? > [...] > > ####################################################################### > ## git-sizer output > > [...] > | Name | Value | Level of concern | > | ---------------------------- | --------- | ------------------------------ | > [...] > | Biggest objects | | | > | * Commits | | | > | * Maximum size [1] | 7.33 MiB | !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! | > [...] The "commit size" that is being referred to here is the size of the actual commit object; i.e., the author name, parent commits, etc plus the log message. So a huge commit probably means that you have a huge log message. This has nothing to do with the number or sizes of the files added by the commit. Maybe your migration tool created a huge commit message, for example listing each of the files that was changed. AFAIK this won't cause Git itself any problems, but it's likely to be inconvenient. For example, when you type `git log` and 7 million characters page by. Or when you use some GUI tool to view your history and it performs badly because it wasn't built to handle such enormous commit messages. Michael
