Merge Train commit hash question
We have lately moved to GitLab users and one of the main reasons is the Merge Train. But the Merge Train has property which we didn’t consider during evaluation and thus I would like to understand fully this property.
As a background we build embedded binaries and store the git hash of the source snapshot to the binary. This hash can be read from the running software at any moment in order to know what is exactly the source base for this binary.
The Merge Train shall run CI pipeline in order to verify that nothing what is tested can be broken once the MR is published in the master.
The problem is: Merge Train seems to create some temporal merge for the verification and afterwards it change somehow the merge before publishing it in the master. My question is why, and can/should it be changed so it will use exactly the same commit in MT and in master?
In our case the binary created in MT provides commit hash which (based on my understanding) cannot be found in the final git history and thus MT binaries are not traceable. As a workaround we can destroy MT binaries after CI pipeline execution and rebuild the binaries after merge, but can we be sure there are no other changes in the binary except the commit hash is changed? So is it somewhere guaranteed the sources are exactly same in MT and in master (after merge) even commit hash is different?
In my head the commit hash shouldn’t be changed in which case the hash itself validates the commit content. But is there some technical reason why this is not implemented this way?