> On 14 Mar 2018, at 09:33, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > > 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. D'oh! Of course. I was so focused on that commit with the large number of files that I missed that. Looking at the reference [1] reveals the problem. Sorry for wasting your time! > 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. Thank you, Lars
