Added test for PR #1645 submodule path

[CosmosAtlas]

Following from here: #1645 (comment), I've added a test in the corresponding position.

Meanwhile, I've noticed there are test failures related to CVE-2022-39253. I did a quick fix in place by adding git configs in the Cmd.

Since I also had the chance to do a fresh start on testing, I updated the docs on where it was unclear to me and caused issues. Particularly, I highlighted that git fetch --tags should be ran first otherwise it would cause test failures regarding version 0.1.6 something something.

Each small change in clearly separated by commits, so if there is any change you don't like, it can be easily cherry picked.

Lastly, I would like to thank you for being so responsive in maintaining this wonderful project 😄

[EliahKagan]

Does this (specifically, 69ab73b) close #1544?

I didn't notice that this PR had already recently been opened, when I subsequently opened #1648. This and #1648 partially overlap in what they fix: they both include changes to two of the existing tests in test_submodule.py, which take different approaches but solve the same problem. I am not sure which approach is better. I've stated the differences between our PRs that relate to #1544, as I understand them, in an edit at the top of #1648.

This pull request also contains improvements not covered in #1648, adding test_ignore_non_submodule_file and updating the readme. #1648 contains improvements not covered here, removing some formerly and newly unneeded git config commands from pythonpackage.yml and cygwin-test.yml workflows.

If this effectively fixes #1544, then it seems to me that it may make sense to extend it to also remove the commands setting protocol.file.allow in the test workflows, but I understand you might consider that beyond the scope of this PR.

[CosmosAtlas]

For future proofness I think #1648 may be better, as I suggested in the original comment, I basically simply edited it for it to work.

Meanwhile, to address the same issue, there's also another approach that seems promising, but I couldn't get it working when tried for a bit.

GitPython supports editing the config file, so in the testing environment, it's possible to just modify the config for the local repo through something like the following

with repo.config_writer() as writer:
    writer.set_value("protocol.file.allow", "always")

[EliahKagan]

If a config_writer-based approach were used, would it be used on the superproject (the repository that is going to have a submodule)? If so, I don't think that will work, because submodules don't inherit local configuration from the superprojects they are added to. I wasn't sure if that applied even to allowed protocols--intuitively it feels like it should not--but it seems it does:

ek@Kip:~/source/repos/example-superproject-ii (main =)$ ls /repos/example-submodule.git
branches  config  description  HEAD  hooks  info  objects  refs
ek@Kip:~/source/repos/example-superproject-ii (main =)$ git submodule add /repos/example-submodule.git
Cloning into '/home/ek/source/repos/example-superproject-ii/example-submodule'...
fatal: transport 'file' not allowed
fatal: clone of '/repos/example-submodule.git' into submodule path '/home/ek/source/repos/example-superproject-ii/example-submodule' failed
ek@Kip:~/source/repos/example-superproject-ii (main =)[128]$ git config protocol.file.allow always
ek@Kip:~/source/repos/example-superproject-ii (main =)$ git submodule add /repos/example-submodule.git
Cloning into '/home/ek/source/repos/example-superproject-ii/example-submodule'...
fatal: transport 'file' not allowed
fatal: clone of '/repos/example-submodule.git' into submodule path '/home/ek/source/repos/example-superproject-ii/example-submodule' failed

[CosmosAtlas]

Thanks for the update. It explained why I couldn't get it working (because it shouldn't!).

[Byron]

Thanks a lot for the test, it's much appreciated! Tests are the reason this project is still on life-support, after all.

Could you rebase onto main and see if the additional -c"protocol… line can the be removed?

Thanks you.

---

Lastly, I would like to thank you for being so responsive in maintaining this wonderful project 😄

Thank you :). I just don't know if it's a wonderful project, but I'll leave that to you ;).