I'm doing something with git-filter-repo that is like the convert-svnexternals script here:
https://github.com/newren/git-filter-repo/blob/main/contrib/filter-repo-demos/convert-svnexternals
In that script, the Git hash for the submodule is associated like this:
dirname = parsed_config[section]['path'].encode()
# Add gitlink to tree
commit.file_changes.append(fr.FileChange(b'M', dirname, git_hash, b'160000'))
However in that script the 'path' section and the name of the Gitmodule section both happen to be the same value. For my script, because the developers using SVN used spaces in the path names (which I wasn't sure if are valid in Git submodule names) and because there will be multiple submodules referencing the same target (so I prepend a svn-externals- or extracted-folder- to say why the submodule exists), no longer is it the case that the key (the name) of the Git submodule is the same as the path. For example:
[submodule "svn-extern-a_path_with_spaces/SomeLib"]
path = "a path with spaces/SomeLib"
url = ssh://[email protected]:7999/FOO/somelib.git
# Same url, different key. They were doing a lot gratuitous
# use of svn:externals in the SVN repository I'm converting,
# and some of them were self-links. So the prior one was a link
# from there to here, within the same repo, that I had to also
# extract out into its own repository to make it a submodule.
[submodule "extracted-folder-AnotherPath/SomeLib"]
path = "AnotherPath/SomeLib"
url = ssh://[email protected]:7999/FOO/somelib.git
Hence my question, should the line with commit.file_changes.append associate the hash with the name of the submodule or with the path?
Or, is it likely to cause more problems having the submodule name different than the path than what might be caused by a submodule name with spaces in it?
