Not too keen on submodules myself, they are a bit of a messy hack. Probably neater to do a squash merge and list which upstream Nuked commit it is being updated to, as we don't really need the whole Nuked commit history repeated again in AdPlug. As long as the Nuked commit hash is present in the AdPlug commit message, it makes it easy for anyone to match it back to the Nuked git history if they wish.

If I do a squash, I can add a list of all the hashes from the original project, and add url to where the original project is located.

The hashes currently are unique for adplug since the commit messages are not 100% carbon copy, the original parent are ours, and the files are not 100% the same due to filename being altered.

You probably don't need to list all the Nuked commit hashes, if you just write something like "Update to NukedOPL commit abc123" then that should be enough to know what point it's at. Knowing that hash is enough to go back through the NukedOPL history to see what changes were made if anyone ever needs to, since each commit hash includes a pointer to the parent commit.

I don't think it's too important to worry about the AdPlug-specific changes. Anyone who wants to know that can just do a diff between the AdPlug file and the upstream one and that will show all of AdPlug's changes.