Being struck by this a couple of times myself, if one component changes too much you end up with a large piece of code that has too much responsibility, never gets rewritten(because it takes too much time) and is bug prone because each commit is tough to know exactly how it affects everything.
If you go with largish modules you need to be smart when you build it, if you build smaller modules you don't have to be that smart. Dumb is good, dumb is easier to explain and read for others (including yourself in 3 years).
So, be dumb keep it simple, whatever that is in your case. If the code is easy maybe a giant repo is good, if the team is small.
If the team is big maybe you have other means of validating access to your repo, but if not you need to split it up. But then commits need to be synced when pushed over several repos..
Edit: make sure it's possible to make clean commits and rewrite the whole code in small steps. Things Will Change(tm)
If you go with largish modules you need to be smart when you build it, if you build smaller modules you don't have to be that smart. Dumb is good, dumb is easier to explain and read for others (including yourself in 3 years).
So, be dumb keep it simple, whatever that is in your case. If the code is easy maybe a giant repo is good, if the team is small. If the team is big maybe you have other means of validating access to your repo, but if not you need to split it up. But then commits need to be synced when pushed over several repos..
Edit: make sure it's possible to make clean commits and rewrite the whole code in small steps. Things Will Change(tm)