git-sizer

Report only statistics that have a level of concern greater than 0

$ git-sizer

$ git-sizer -v

$ git-sizer -h

git-sizer [<options>] [<commitish>...]

--format=<format>
    Specifies the output format. Common options include human (default), json, and csv.

--threshold=<threshold>
    Sets a general size or count threshold. Any metric exceeding this value will be flagged in the output.

--json
    Outputs results in a machine-readable JSON format, suitable for scripting and automated analysis.

--no-progress
    Suppresses the progress indicator shown during repository analysis, useful for non-interactive scripts.

--no-walk
    Disables walking the commit graph. This can significantly speed up analysis by only examining loose and packed objects, but provides less comprehensive data related to history depth.

--tags
    Includes all tags when analyzing the repository, expanding the scope beyond just branches.

--branches
    Includes all branches when analyzing the repository (default behavior if no commitish is specified).

--all
    Analyzes all references (branches and tags), providing a complete repository overview.

<commitish>
    One or more commit hashes, branch names, or tags to limit the scope of the analysis to specific parts of the repository history. If omitted, all local branches are analyzed.

git-sizer is a powerful tool for analyzing a Git repository's size and internal characteristics, helping identify potential performance bottlenecks or problematic growth patterns. It thoroughly examines various aspects, including the total number of objects, their combined packed size, the depth of the commit graph, and the size of individual blobs and trees. This utility is indispensable for repository administrators and developers aiming to proactively manage repository health, pinpoint excessively large files (often candidates for Git LFS), or understand the root causes of slow operations like cloning or garbage collection. By providing detailed, actionable metrics, git-sizer facilitates the optimization of repository structure, ensuring more efficient and manageable Git workflows.

Analyzing very large repositories without the --no-walk option can be time-consuming due to the extensive graph traversal.
The reported sizes primarily reflect packed object sizes, which may differ from the actual on-disk space occupied by the Git repository.
git-sizer identifies potential issues but does not provide direct solutions; it guides further investigation or action (e.g., using Git LFS for large files or git-gc for optimization).
It requires a local clone of the repository to perform its analysis; it cannot directly analyze remote repositories.

git-sizer reports on a wide array of metrics, providing a comprehensive view of repository structure and content:
- Total Objects and Total Packed Size: Overall repository bulk.
- Maximum Blob Size and Maximum Tree Size: Identification of large individual files or deeply nested directory structures.
- Maximum Commit Depth and Maximum Tag Depth: Indicators of long history or deep reference chains.
- Maximum Path Length: Helps identify files with excessively long absolute paths within the repository.
These metrics collectively help pinpoint specific areas of concern that might impact performance, maintainability, or compatibility with various file systems.

A powerful feature of git-sizer is the ability to define custom thresholds for individual metrics (e.g., --max-blob-size-threshold=100MB) or apply a general threshold to flag any metric exceeding a specified limit. This feature significantly enhances the utility of the tool by allowing users to quickly identify and focus on areas that violate their defined repository health policies, performance benchmarks, or organizational standards, streamlining the identification of problematic assets.

git-sizer emerged as an external Git command, independently developed to address the growing need for repository size analysis in increasingly large Git projects. Its popularity surged as organizations faced performance challenges with massive repositories, particularly concerning cloning times and general repository bloat. It fills a critical gap in the Git ecosystem by offering detailed insights into repository health, empowering users to proactively identify and manage growth patterns. Its ongoing development focuses on enhancing the accuracy and utility of its diagnostic capabilities within modern Git workflows.

git(1), git-lfs(1), git-gc(1), du(1)