Benchbuild cache coherence for git tmp folder

[vulder]

Currently, benchbuild does not detect when the git folder, cached in tmp, is outdated, i.e., there are new commits upstream.
It would be helpful to add an initial fetch before, e.g., version exploration, so BB could discover a newer version that is present upstream.

I guess this conflicts with BB's current state management and could make problems when one want's to reevaluated the currently cached HEAD revision. So, maybe we could add the 'fetching' as a, via config, enableable feature.

[simbuerg]

We can implement that for git sources by default. If a project states that it follows 'HEAD' you cannot assume to have a fixed source in the cache.

If you want a stable and reproducible experiment run, you have to use a project that uses fixed versions.
An example that follows HEAD would be benchbuild/bzip2. In the past I never touched the cache to avoid
any surprises and updating the project every time I want to test a new version was cumbersome.

This behavior was the default before we implemented support for multiple versions per project. If I'm not missing an edge-case, there should not be a problem with a remote update + fetch.

[vulder]

Update + fetch should be enough that does not change the repo state in the cache but pulls in the information of other commits added to remote HEAD. And yes, if a project specifies HEAD one cannot assume that it will always be the same and having a specific tmp/checkout locally is more 'happens to work'. That was a reason why we introduced paper_configs and case_study files that exactly specify which revisions should be locked at.

If a BB user want's to pin a revision, one option could be to inherit from the project, give it a unique name and pin the version.