Feature
It seems that as of 1.5.0, git metrics has a single mode that analyzes all commits in the repo.
It could be interesting to support a few other ways to analyse the repo, like:
- Check all refs (as it's the current case)
- Only check the current/main branch
A stretch:
- Compare all branches against current/main branch, one by one, and find the ones with the biggest diff in object count/disk size.
Explanation
I'm currently analyzing a repo which is ~20GB in --single-branch clone mode, vs ~38GB when all 10k+ branches are cloned. I'm trying to figure out whether the 18GB diff is due to just 10k branches x small diff in each, or are there some "rogue" branches that disproportionately affect the size.
(By accident, I already found one rogue branch which had a completely unrelated git history pushed over by mistake, with a different root commit -- essentially it was a different repo that was pushed into the current one due to a messed up git config of a contributor -- which got me interested in pursuing this further).
Notes
Re: (2) the current workaround is just to git clone --single-branch on the side, and run git metrics in that clone; it's fine, but just wasteful.
Re: (3) to be frank, I know that it might be quite expensive to calculate.
Feature
It seems that as of 1.5.0, git metrics has a single mode that analyzes all commits in the repo.
It could be interesting to support a few other ways to analyse the repo, like:
A stretch:
Explanation
I'm currently analyzing a repo which is ~20GB in
--single-branchclone mode, vs ~38GB when all 10k+ branches are cloned. I'm trying to figure out whether the 18GB diff is due to just 10k branches x small diff in each, or are there some "rogue" branches that disproportionately affect the size.(By accident, I already found one rogue branch which had a completely unrelated git history pushed over by mistake, with a different root commit -- essentially it was a different repo that was pushed into the current one due to a messed up git config of a contributor -- which got me interested in pursuing this further).
Notes
Re: (2) the current workaround is just to
git clone --single-branchon the side, and rungit metricsin that clone; it's fine, but just wasteful.Re: (3) to be frank, I know that it might be quite expensive to calculate.