Version 0.3.0 moved Blob and InspectBlob to an in-process go-git reader to speed up Scrutineer's repeated history reads. The change cuts the current blob benchmark from about 7.36 ms to 0.25 ms on an M1 Pro, so that fast path should remain available to Scrutineer.
The object-store implementation lives in the root clone package, which also means consumers using only Ensure or RedactURL compile the go-git storage packages. While updating Hyrum, changing only clone from v0.2.1 to v0.3.0 changed its module graph from 136 to 161 modules and its non-standard compile closure from 135 to 173 packages. The linked binary grew by about 106 KiB because the linker removed the unused blob-reading functions, but the build, go.sum, SBOM, and dependency-review surface still grew.
Steps to reproduce:
- Check out
alpha-omega-security/hyrum.
- Run
go list -m all and go list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./cmd/hyrum with clone v0.2.1.
- Run
go get github.com/git-pkgs/clone@v0.3.0 && go mod tidy.
- Run the two listing commands again.
Could the fast reader move behind an opt-in package or module boundary, with Scrutineer importing that backend directly? The aim is to keep its current history-reading speed while letting clone/fetch-only consumers avoid the extra graph. A normal subpackage would reduce their compile closure, but a nested module would also keep go-git out of the root module graph.
Version: github.com/git-pkgs/clone v0.3.0.
Version 0.3.0 moved
BlobandInspectBlobto an in-processgo-gitreader to speed up Scrutineer's repeated history reads. The change cuts the current blob benchmark from about 7.36 ms to 0.25 ms on an M1 Pro, so that fast path should remain available to Scrutineer.The object-store implementation lives in the root
clonepackage, which also means consumers using onlyEnsureorRedactURLcompile thego-gitstorage packages. While updating Hyrum, changing onlyclonefrom v0.2.1 to v0.3.0 changed its module graph from 136 to 161 modules and its non-standard compile closure from 135 to 173 packages. The linked binary grew by about 106 KiB because the linker removed the unused blob-reading functions, but the build,go.sum, SBOM, and dependency-review surface still grew.Steps to reproduce:
alpha-omega-security/hyrum.go list -m allandgo list -deps -f '{{if not .Standard}}{{.ImportPath}}{{end}}' ./cmd/hyrumwithclonev0.2.1.go get github.com/git-pkgs/clone@v0.3.0 && go mod tidy.Could the fast reader move behind an opt-in package or module boundary, with Scrutineer importing that backend directly? The aim is to keep its current history-reading speed while letting clone/fetch-only consumers avoid the extra graph. A normal subpackage would reduce their compile closure, but a nested module would also keep
go-gitout of the root module graph.Version:
github.com/git-pkgs/clonev0.3.0.