There's going to be a little fixup to do because you're wanting to discard all the evidence of that proxy repo (../BigRepo), but it's not hard.
Easiest from here is probably to just redo the submodule add with what you have, do that by
# undo the in-repo add mv BigRepo ../agggh_I_meant_to_add_this_from_outside git rm --cached BigRepo git config -f .gitmodules --remove-section submodule.BigRepo git config --remove-section submodule.BigRepo
And your backout is complete.
Now, if you add a submodule from a local, unpublished repo you have to then correct the urls later for the convenience of others, but that's straightforward:
# Get `git submodule add` to do the hoisting for you git submodule add ../agggh_* BigRepo # but from now on use u://r/l as the submodule's published repo: git config -f .gitmodules --set submodule.BigRepo.url u://r/l git config --set submodule.BigRepo.url u://r/l # alternate spelling of `git submodule sync BigRepo` here # and the published repo is my copy's `origin` too git --git-dir=BigRepo/.git remote set-url origin u://r/l
(
edit addressing questions in comments:
The mv/clone-from-the-mv'd-one pair is because perhaps you've done, or done and forgotten, some work there, and so ../BigRepo might be out-of-date. It's just a safety play; a rm -rf BigRepo and later git submodule add ../BigRepo would work as well if the currently-added one is really discardable.
I can't figure how any of the submodule adds above could provoke network activity -- ../anything is on the same filesystem as ../ThisRepo i.e. ., right? git clone of a plain same-filesystem path, relative or absolute, does dirt-cheap hardlinks unless you take steps to provoke an actual copy -- this works even on NTFS. It's only if you specify a full url or otherwise force the issue that git creates a full-copy clone. Maybe it's just the caffeine kicking in unusually slowly, if I'm missing something please, whoever sees it, just edit it in or edit this whole paragraph out.
)
