Menu
I'm wondering if there's an upper limit to the number of commits that a git repository can handle.
In a solo project I'm working on right now, I've been coding locally, committing/pushing changes in git, then pulling the changes on my development server.
I treat this as an easier alternative to working locally and uploading changes via FTP... Fortunately/Unfortunately it's such an easy workflow that I sometimes go through many edit/commit/push/pull/browser-refresh cycles while coding.
I'm wondering if this is going to turn around and bite me somewhere down the line. If it's likely to be a problem, I'm wondering how I can avoid that trouble ... It seems like a rebase might be the way to go, especially since I won't have to worry about conflicting branches etc.
868
Maximum git repository size is 10GB The total git repository size will be limited to 10GB. Warnings and error messages will be alerted to you as your repository size grows, to help ensure that you are aware of reaching or approaching the size limits.
This error occurs when a push directly to a branch bypassing review contains more commits than the server is able to validate in a single batch.
The maximum lengths of the subject and message body can be configured in the standard Gerrit config file gerrit. config . The defaults are 50 characters for the summary and 72 characters for the description, as recommended by the git tutorial and expanded upon by Tim Pope.
File size limitsGitHub limits the size of files allowed in repositories. If you attempt to add or update a file that is larger than 50 MB, you will receive a warning from Git. The changes will still successfully push to your repository, but you can consider removing the commit to minimize performance impact.
Well the "upper limit" would likely be the point at which a SHA1 collision occurs, but since the SHAs are 40 hexadecimal digits long (16^40 ~ 1.4x10^48 possibilities), it's so close to zero possibility that it's not even funny. So there's roughly a zero percent chance you'll have any problems for at least the next several millennia.
Hyperbolic Example (just for fun): 1 commit/minute (just changing one file -> three new SHAs used (file, commit, tree) = 3 new shas used / minute = ... = 1.6M shas used / year = 1.6 Billion shahs / millennia = 1x10^-37 % used each millenia... (at 1000 files/commmit/min, it's still 3.6x10^-35%)
That being said, if you want to clean up your history, squashing them down with rebase is probably your best bet. Just make sure you understand the implications if you've shared the repo publicly at all.
You might also want to garbage collect after rebasing to free up some space (make sure the rebase worked right first, though, and you might need to tell it to collect everything or it will, by default, not collect anything newer than two-weeks old).
178
I'm pretty sure you don't have to worry at all :)
Git is using SHA-1 hash in order to check files, the probability of having an hash conflict is near zero. So have fun !!
I personally did around 30 commits a day without issue.
But avoid versioning binaries files :) it's really heavy for what it is.
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
