7 ms·

There 100% is at least for things like secret scanning and message parsing. Secret scanning needs to make sure my repo as a whole has no secrets. It’s not acce

There 100% is at least for things like secret scanning and message parsing. Secret scanning needs to make sure my repo as a whole has no secrets. It’s not acceptable to have 1 commit introducing it and 1 removing it because the secret is still recoverable. Every commit is also surely an entry in a database somewhere. I can navigate in GitHub directly to any individual commit so there is definitely some overhead of some type.

jeremyjh 27d ago
You are right about secret scanning, but its worth noting that is only enabled by default on public repositories. It is an extra paid feature for organizations on a teams or enterprise subscription, and isn't available at all for individual owned repositories outside of an enterprise subscription. And yes, I agree there is indexing of commits, but that is a batch insert from a log.
tremon 27d ago
It's not necessary to perform secret scanning on a per-commit basis. The most efficient way is to just scan all blob objects being pushed; there is no reason to even be aware of an object's location (tree path or commit) except for diagnostic messages. > I can navigate in GitHub directly to any individual commit You can do the same with the git command line client. The overhead you claim is already in the git on-disk format. Github might very well duplicate this information in a database somewhere, but it doesn't follow from your observation.