11–20 of 29 posts
Golang binaries embed the version of the compiler into them, and can easily add git revision information too. That's a nice feature for adding "foo -version", or similar, to show the users what their binaries were built from.
Relatedly, GCC/binutils still has a `.ident` assembly directive ( https://sourceware.org/binutils/docs/as/Ident.html ) and `#ident` preprocessor command ( https://gcc.gnu.org/onlinedocs/cpp/Other-Directives.html ) that emit data into an ELF .comment for `what` to read...
This was at Bell Labs Columbus Ohio. Also, I think it was COFF and not ELF. Used System V r2.
I used to use these embedded version strings, and occasionally they were very helpful. As the article says, it's not as easy a fit for Git. The embedded version etc. strings could also make reproducible builds slightly more tricky than they already are. Even if they're not worth the trouble for current software, they could be a big timesaver for archaeology/reconstruction of old software.
It was easy enough to replace with a short script, and I use a variation of that to this date
I don't see this, or binary .ident strings as e.g. clashing with idempotent builds.
Golang binaries embed the version of the compiler into them, and can easily add git revision information too. That's a nice feature for adding "foo -version", or similar, to show the users what their binaries were built from.
Here's a nice blog post with more information about that https://blog.carlana.net/post/2023/golang-git-hash-how-to/
[0]: https://github.com/peterldowns/localias/blob/main/Justfile#L...
I used to use these embedded version strings, and occasionally they were very helpful. As the article says, it's not as easy a fit for Git. The embedded version etc. strings could also make reproducible builds slightly more tricky than they already are. Even if they're not worth the trouble for current software, they could be a big timesaver for archaeology/reconstruction of old software.
For Git, you could embed a string of the form: :path/in/repo/to/file.ext to be able to retrieve the exact source file contents used to build something.
Years ago, when moving off svn to git, I cursed the fact that there was no such string replacement feature. I understand why it doesn't exist, but when it was an obstacle to my job, I loathed it. It was easy enough to replace with a short script, and I use a variation of that to this date
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute... look under "Keyword Expansion" halfway down the page.
The worst ones are the ones that expand the log messages, when they are implemented in such a way that it becomes permanent.
A wall of short commit messages condensed into a block comment don't help anyone understand anything, without the actual changes to refer to.
Keywords are supposed to help someone who works outside of the context of the version control, but that's ironically the person who is trying to apply a patch that is failing because of the expanded cruft, whereas the person working in the version control system may have a way to do the merge on unexpanded artifacts.