Print the latest git commit's SHA1 upon starting a simulation
SchDvr opened this issue · 7 comments
Print the latest git commit's SHA1 upon starting a simulation
Summary
This change would allow the user to see exactly which version of CB-Geo is running by printing to the console the latest commit's SHA1 before anything else. The first line displayed by CB-Geo would look like that :
[2021-02-17 00:09:02.219] [main] [info] git revision: 1fa330e756a986e332bffef224395d33f8a75d4e
Motivation
This feature would help users organizing their results and thus improve the reproducibility of their work. It should also be useful when developing a new feature.
Design Detail
This change would use this project which was developed by Andrew Hardin for this purpose. It is also under a MIT License.
Three files would be added and one would be created by make :
cmake/git_watcher.cmake, to addinclude/git.h, to addinclude/git.cc.in, to addinclude/git.cc, generated frominclude/git.cc.inby make
The CMakeLists.txt file would be modified to include cmake/git_watcher.cmake but also to create and link a new library named git (as it is done in the project mentioned above).
The line that prints the commit's SHA1 would be added in the src/main.cc script, right after the initialization of the logger.
Drawbacks
The addition of several files may reduce the code's readability.
Rationale and Alternatives
The two main alternatives that can be found with a google search are summed up here. Those alternatives either do not see the changes made after running cmake or needs to recompile some files even though no changes were made.
So according to Andrew Hardin, his solution is better.
Hi @SchDvr
Thanks for opening this. The example from Hardin looks quite straight forward. I agree this would be good in terms of reproducibility and helpful information to include.
Two thoughts:
-
developshould always be the "best" version of the code. So if old results aren't being reproduced on the currentdevelop HEAD, the old results probably have some errors and need to be rerun anyway. -
I have had the experience where I know I will need to reproduce results (regardless of improvements/fixes to CB-Geo) and I've always just made a copy of
developinto a new branch in my personal repo prior to pulling anydevelopupdates.
Including the commit's SHA1 would give options for user workflow.
Thanks for your approval. I made the changes on my computer, should I open a pull request?
Thanks @SchDvr That would be great! Please create a PR and we can test it and merge :)
I tried to push the new branch but I don't have the permissions. Is there something else I should do before "git push -u origin new_branch" ?