softwarepub
Reverse precedence of configured harverster results during merge
At the moment successive merge steps belonging to successive harvester runs override previous values on pre-existing keys.
Harvesters are and their merge steps are executed in the order they are listed in the harvest section of the configuration, leading the last one to take precedence. This seems counter-intuitive, especially considering the current default/example hermes.toml:
https://github.com/hermes-hmc/workflow/blob/05e4e530af77bd38810dd802c5c4f1b8249a8ca5/hermes.toml#L5-L6
where a value produce by the git harvester, which could only be a commit hash, would override a value read from a CFF file. #154 does not change this behavior apart from storing the previous value as an alternative.
The are two general ways to address this: either
- run the harvesters in reverse order, or
- invert the behavior the the merger to not touch existing values (and add new values as alternatives in #154 ).
Note, that the second option cannot left for the individual harvesters to implement, because
- this would make implementing a merge strategy mandatory for each harvester, to the detriment of the harvester developers, and
- would allow for inconsistent harvester precedence, to the detriment of the user.
In principal, this behaviour could be easily implemented in the current code (at least to flip the precedence).
Do we want that already in Proof-of-Concept? We should definately re-consider it when discussing the breaking changes for Alpha.
The order is flipped so the first harvester source is the most important.
