Will it help if we are consistent in our use of merge_pr_in_ci in Packit configuration file?

[mulkieran]

merge_pr_in_ci key has the following effect (https://packit.dev/docs/configuration#merge_pr_in_ci);

"
(bool) When Packit clones your repository while creating RPMs from your pull requests, it by default merges the pull request checkout into the main repository branch to be sure the changes are up to date. You can disable this behaviour by setting this field to false which will make Packit to work with your pull request git ref as it is.

When your pull request can not be fast-forward-merged into the target branch, setting this key to false can be especially useful not to generate RPM packages with an NVR referencing an unknown hash (the one created by the Packit merge commit).
"

We set this to false in stratisd and stratis-cli in order to be able to use the commit hash of the top-level commit as an identifier always, so that there would never be the hash of a merge commit generated by Packit to contend with.

When the PR is up-to-date with the target branch, no merge commit is generated, a "fast-forward" merge occurs. Otherwise, though, the merge commit is created.

It may be having another effect as well, though, which I'm still not sure of. It seems to change how the COPR repo for the PR is named in the presence of identiifers. When merge_pr_in_ci is set to false, the identifier seems to end up on the end of the repo name for a PR. When merge_pr_in_ci is not set, default is true, the identifier name seems to not be added.

We want as much consistency as possible. Should we add merge_pr_in_ci key to Rust library Packit configurations and pay the one time cost of the name change? Let's see what happens, anyway.