I built git-sha-ready after noticing that a Git integration can appear healthy while it assumes every object ID is 40 characters long. That assumption works for a SHA-1 repository. A SHA-256 repository uses 64 hexadecimal characters, so a validator can reject a real commit and a fixed slice can discard part of its ID.
My small fixture starts with a validator that accepts exactly 40 hex digits and a slice(0, 40) call. The scan reports the file and line for each one. After I let the validator accept 40 or 64 digits and remove the fixed slice, the same scan has no findings. The GIF above records the real CLI on that fixture.
The default command reads Git tracked text files. It does not execute the target project. I look for five families of patterns: 40 hex regular expressions, length comparisons to 40, fixed 40 character slices, direct .git/objects access, and 20 byte object ID storage. Each finding has a confidence label and a short repair hint. A checksum unrelated to Git is marked for review rather than treated as a confirmed defect.
I also added an explicit --probe mode. It copies tracked source and config files into a temporary repository initialized with SHA-256, makes a local commit, and runs a shell command supplied by the user. For a Node project, I can use git-sha-ready --probe 'npm test' after making sure the command installs what it needs. The temporary repository is removed when the command finishes. I treat this as a local compatibility check, not as a substitute for testing a full deployment path.
There are limits I want to be clear about. This is a text pattern scanner. It can miss multiline code, aliases, generated code, and less common spellings. A green scan score means the supported patterns were absent in the files examined. It does not certify SHA-256 compatibility. The optional probe executes a user chosen shell command, so I only use it with a command I trust.
The project includes the fixture, tests, a CI workflow, and the install command in the README. I would like reports from maintainers of Git clients, build tools, and release scripts. A short example with the expected behavior and the actual finding would help me improve the rules without adding noise.
Top comments (0)