3 ms·
There are also cases where multiple VCS tools are used or where you might want to build from an archived full copy of source+vendored dependencies and might not
by matheusd 5y ago
There are also cases where multiple VCS tools are used or where you might want to build from an archived full copy of source+vendored dependencies and might not even have an underlying VCS to speak of.
Reproducible releases should probably _not_ have these commit metadata built in (e.g. imagine reproducible building this 5 years in the future where you've moved off git). Though this is quite useful in debug builds where you might be have installed a number of different builds in the wild and want to be able to quickly figure out the exact version of the code a given binary was generated from.
- grumbel 5y agoI would include the commit metadata, otherwise you have no easy way to figure out where that source came from. The issue of out-of-VCS builds can be solved by putting the commit-hash into the directory/tarball name or a VERSION file, e.g. $PROJECTNAME-$(git describe --tags | sed "s/^v//"). When converting VCSs most converters will preserve the old hash in some form, e.g. by appending it to the commit message. Github downloads however remain a problem, as they just include the branch name, not the commit hash.