I have a GitHub repo used to track changes in a set of small scripts (all functionally independent).
I also am part of a lab GitHub repo used to collect useful scripts written by various people in our group.
I want to push changes made to my scripts to the shared repo, but I don't want to have them be exclusively tracked under that repo, nor do I want modifications made there to overwrite my master copies.
The approach I've taken is to run a command to copy the scripts into the shared repo every time I change something, but this means I have to make a separate commit in that repo, too. Every time I Google this I end up at an answer mentioning
The problem you'll run into is the phrase "commits...for only those files". The complete content tree is an integral part of a git commit. For example, if you use
git filter-branch with the
subdirectory-filter, it appears to modify every commit to remap a specific directory as the worktree root; but it doesn't really do that because it can't. What it does is create new commits, with a history parallel to the old commits, with the modified work tree directory structure.
If you can structure the shared repository so that each contributor's scripts get their own directory, then submodules would indeed be an option. I understand you feel it's over-engineered, but that's based on your thinking that moving "part of a commit" is an easy idea, which is leading you to underestimate how much complexity you should encounter.
Otherwise, I think finding a way to automate the copy-based approach is the best you'll get.