git keeps changing the number of digits in abbreviated hashes, resulting in the GitHub archive hash changing because we include it here. To workaround this and avoid hashes that become increasingly ambiguous later on, just include the full commit hash when building from git. This has no effect on tagged releases.
(Cleanly mergable back to 0.10 without backport)
git keeps changing the number of digits in abbreviated hashes, resulting in the GitHub archive hash changing because we include it here.
To workaround this and avoid hashes that become increasingly ambiguous later on, just include the full commit hash when building from git.
This has no effect on tagged releases.
ACK, I strongly prefer full hashes as they will remain unambiguous for all time, https://github.com/bitcoin/bitcoin/pull/11966/commits/a71c56aebbd93b25fcdbc170bd8b451e52a6b4dd
Sounds very sensible, utACK https://github.com/bitcoin/bitcoin/commit/a71c56aebbd93b25fcdbc170bd8b451e52a6b4dd
ACK.
utACK a71c56aebbd93b25fcdbc170bd8b451e52a6b4dd How does the GUI splash screen looks like with this?
utACK a71c56a I don't think this should have any affect on the splash screen, the version string should always be sized to fit.
How does the GUI splash screen looks like with this?
That's a good point. Wasn't able to find any difference.
Hrm so this will only make a difference with git-archive?
Built and verified the splash screen is unchanged, this change is embedded in a #ifdef GIT_ARCHIVE, so doesn't affect the normal build which uses BUILD_DESC_WITH_SUFFIX - which gets the suffix from share/genbuild.sh, i.e. the short version:
Did you build from an archive to verify that?
utACK a71c56a