When you are adding or editing a module, you have a number of options, that determine, how the Git history from the module is integrated into the parent repository.
All these options only affect the way the Git history is represented in the parent repository. The actual files, imported from the modules, and the Git history of the modules are always the same.
This option determines, whether the commit-graph from the module is merged into the parent graph ("merge"), or placed on top of it ("inline"). The difference is similar to that of "git merge" and "git rebase".
Commits from the module tree are merged into the parent tree, like an external branch.
Commits from the module tree are included in the parent tree on the top of the existing commits.
You may "squash" the commit history from the module down to one last commit instead of including it in the parent graph completely.
Adding a module adds just one commit to the parent graph, which contains the most recent state of the module repository. After the module is added, all future commits to the module will be added to the parent graph one by one.
Each time there're new commits to the module repository, only one commit is added to the parent graph, containing the most recent state of the module repository.
All commits to the module are added to the parent graph one by one.
"Squash Once" and "Squash Always" will render the same result in most cases, because the Git X-Modules app is fetching updates from the module repository every minute, and it's unlikely that more than one new commit appears there between polls. However, if a longer polling interval is set, or many people are committing to the module repository, it's possible, that Git X-Modules fetches several new commits with one poll. In such a case, if the "Squash Once" option is selected, all these commits will be applied to the parent graph separately.
You can use any combination of Merge Strategies and Squash options. You can also change these options on the existing X-module.
Please note, that if you want to preserve the commit hashes after the synchronization, then Subtree Merge + Squash Never is your only option. All other variants will copy the commits with the hashes changed.