Immediate Fix
If your system is freezing or the CPU fan is spinning at maximum speed during a Git operation, the fastest solution is to limit the number of threads Git uses for packing objects.
Run the following command in your terminal to limit Git to a single thread. This prevents Git from consuming every available CPU core:
git config --global pack.threads 1If you want to allow some multi-threading but still keep the system responsive, you can set it to a specific number of cores (e.g., 2):
git config --global pack.threads 2Additionally, you should limit the memory used during the windowing process to prevent the system from swapping to disk, which often accompanies high CPU usage:
git config --global pack.windowMemory 512mTechnical Explanation
The git pack-objects command is the engine behind Git’s data compression. Its job is to group individual objects into “packs” and find “deltas”—the differences between files—to minimize disk space and bandwidth.
Finding these deltas is a computationally expensive process. By default, Git attempts to use as many CPU cores as possible to speed up the compression. On large repositories or those with many binary files, this multi-threaded search can saturate the CPU.
The “Overheating Warning” typically occurs because Git is performing a deep search for delta candidates. When multiple cores are engaged in high-intensity floating-point calculations and memory access, thermal throttling often kicks in.
Alternative Methods
If limiting threads doesn’t fully resolve the issue, you can modify how Git handles its internal database and garbage collection.
The following table summarizes configuration tweaks that can lower the resource footprint of pack-objects:
| Setting | Command | Benefit |
|---|---|---|
| Delta Depth | git config --global pack.depth 10 |
Reduces the maximum delta chain depth, saving CPU. |
| Window Size | git config --global pack.window 10 |
Limits how many objects Git compares at once. |
| Compression Level | git config --global core.compression 0 |
Disables compression entirely (faster, but uses more disk). |
Another effective method is to run a manual garbage collection. This pre-calculates the packs so that push and fetch operations don’t have to do it on the fly:
git gc --aggressive --prune=nowFinally, if you are working with a massive repository and only need the latest history, consider using a shallow clone. This drastically reduces the number of objects Git has to process:
git clone --depth 1 [repository-url]