py/makeversionhdr.py: Always abbreviate Git hashes to same length. #17832
+10
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The Git hash is embedded in the version number. The hash is abbreviated by Git. This commit changes the length of the Git hash abbreviation to a fixed number, so that the length of the version string no longer varies based on external factors.
Made this change because builds of the same MicroPython commit on multiple machines were sometimes giving a version string with different lengths. This change may also help the code size report to be more consistent, because it will less often be impacted by random changes in the version string length, at the cost of always being a few bytes longer.
Testing
By default Git chooses the length "based on the approximate number of packed objects in your repository" (man page). This was causing the version string length to be unstable depending on how big your local repository is.
At the moment of writing, the
master
branch on GitHub contains 17463 commits. Based on the statistics from my own repository, I set the value to 10, which is one higher than the highest value I saw required for a unique commit abbreviation in my local repository checkout:Trade-offs and Alternatives
Alternative is to not do this. Then we don't get the consistency benefits, but will keep semi-randomly saving a few bytes for years to come (until the default gets increased by the Git heuristic).
Note that Git will still use more characters if it required to make the hash unique. So all this setting does is increase the minimum slightly; Git will still use a longer hash if it already knows about another commit with the same abbreviation.
We can always safely increase this number later should the need arise.
Note: Presumably the users with the largest repositories are the core maintainers, so perhaps they could check the statistics for their repository and report if they think a length of 10 is the right choice.