If you really don't want the HFIX-7788 to be committed in your Pega 6 environment, then you can ignore this error if this Hotfix instances are not migrated to your Pega7 env, since your upgraded environment is working fine.
However if you still want to make sure if all the other required table and data are migrated properly. You need to check your migrate.logs
In the beginning of the log file, it would list all the tables to be migrated, I believe the list of tables are temporarily stored in tables.txt when you run the script. There will be entry in logs when each table is being loaded to the target schema with statements of how many rows are committed.
If you see all the tables listed are loaded properly in the target schema except the few rows of the uncommitted HFIX instances then it should be good.
In my experience, we have tended to not always commit hotfixes as this keeps open the possibility of rolling them back if necessary, and of course an uncommitted hotfix still works fine. I'd suggest that if an application is in a stable state ready for upgrade, a pre-requisite to doing this would be to consider committing all uncommitted hotfixes - maybe this could be added to pre-upgrade checklists in future. This would hopefully avoid any errors as reported above which may create doubt as to the success of the upgrade - even if it is successful as this one appears to have been. Maybe something for others to consider who haven't upgraded yet.