One workaround I've considered (but not tried) is to initialize the submodule codebase ("subsystem1.git" in your example) as an independent, local repository. Add a "remote" in the submodule which points to the independent, local version of the repository. Also add a "remote" in the non-submodule (indepent, local) version of your subsystem repository which points to the submodule version. You should then be able to use Samba / Windows / Linux to update the independent (non-submodule) version of subsystem1.git, and then "git fetch independent" from within the submodule to copy the code from the non-submodule repository to the submodule repository.
At the end, your directory structure should look something like:
/mnt/gitrepos/
/mnt/gitrepos/subsystem1.git/
/mnt/subsystem1.git/
The remotes in each of these repositories would look like the following:
/mnt/gitrepos/.git/config would have one remote block:
[remote "origin"] (points to your main, non-local repository)
/mnt/subsystem1.git/.git/config would have two remote blocks:
[remote "origin"] (points to your main, non-local repository)
[remote "local_origin"] (points to /mnt/gitrepos/subsystem1.git)
/mnt/gitrepos/.git/modules/subsystem1.git/config would also have two remote blocks:
[remote "origin"] (points to your main, non-local repository)
[remote "independent"] (points to /mnt/subsystem1.git)
Synchronizing your submodule's code with what's on the remote server then becomes a multi-step process, since you have to use the "independent" repository as an intermediate repository / staging area.
Your Mileage May Vary... This is just a thing that seems like it should work, not something I've tried.