If they're showing up then they are "real" changes (meaning someone saved the file again and checked it in). This means the timestamp changed and there's a new changeset with a metadata change (timestamp, user who committed it, etc). That means in order to fully merge you need to reconcile those differences (by either accepting the new version with unchanged content, or rejecting the new unchanged version in favor of the old unchanged version).

If your developers/users are committing unchanged files, then that's a process problem and they should stop that. Your diffs and merges would be cleaner.

In the options for Pending Changes -> "What to find", ensure that your users have "Check the content to determine files as change, not only timestamp" as checked. That should help reduce the number of non-changed files that they check-in. But ultimately it's up to them to not to do this.

If you don't want any user to be able to check-in a file where the contents haven't changed, you could implement a server-side trigger on "before-checkin" and reject the commit if it contains any files that are unmodified per your requirement. (https://www.plasticscm.com/documentation/triggers/plastic-scm-version-control-triggers-guide#Checkin)