search

github / git-sizer

Compute various size metrics for a Git repository, flagging those that might cause problems
MIT License
3.56k stars 143 forks source link

Advice for alleviating found issues? #22

Closed hexpunk closed 6 years ago

hexpunk commented 6 years ago

TL;DR

I really like this tool. One thing I would like, though, would be if it could suggest ways to fix or otherwise deal with the issues it finds. (I don't know if this is always possible for every type of issue this tool can detect.)

The Long Version

I'm a programmer who uses git every day and I'm familiar with how to do the common stuff like cloning, branching, committing, merging, etc. I've been using it for years. I read Version Control with Git, so I have a decent understanding of how git works. I've written a program that uses Rugged, the Ruby bindings to libgit2. I'm even familiar enough that I can do more advanced stuff like interactive rebasing for editing commit messages or author info, and for squashing commits. I can do non-interactive rebasing to clean up branch histories.

Point is, I'm familiar with how git works and how to use it. But I'm not familiar with git's performance profile. That's how I've been using git-sizer the past few days. I've been running it on the various repos to which I contribute to see what pops up.

But once it tells me that certain objects/trees/tags/whatever are potentially problematic, then what? Is there something I can do to fix that, or is the tool just telling me my repo is screwed? 😉

mhagger commented 6 years ago

The project README (which is visible on the project page) gives a lot of generalized tips for dealing with various problems that can be detected by git-sizer. Though I agree that it's not always obvious from the git-sizer output which of these problems the repository is suffering from. We could explain that better.

It would also be thinkable for the program (perhaps when some new --advice option is specified) to try to summarize the problems that it found at a higher level of abstraction and to emit some possible recommendations for how to fix it.

Most fixes would involve rewriting the project's history, for example using git filter-branch or the BFG repo cleaner. Unfortunately, rewriting history is somewhat fiddly and also rather disruptive if the project has many collaborators. Part of my hope with git-sizer is that it helps people detect problems before they are so critical that they require a history rewrite.

I'm closing this issue because it's not actionable in its current form. If you have more specific requests or ideas, feel free to reopen or to open a new issue or PR.