Print the latest git commit's SHA1 upon starting a simulation

[SchDvr]

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 add
• include/git.h, to add
• include/git.cc.in, to add
• include/git.cc, generated from include/git.cc.in by 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.

[jgiven100]

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:

• develop should always be the "best" version of the code. So if old results aren't being reproduced on the current develop 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 develop into a new branch in my personal repo prior to pulling any develop updates.

Including the commit's SHA1 would give options for user workflow.

[SchDvr]

Thanks for your approval. I made the changes on my computer, should I open a pull request?

[kks32]

Thanks @SchDvr That would be great! Please create a PR and we can test it and merge :)

[SchDvr]

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" ?

[kks32]

Hi @SchDvr please create a fork of cb-geo/mpm to your personal repo and then create a PR from there.

[SchDvr]

Thanks, I just opened a draft PR.

[kks32]

Fixed in #707