Am 17.07.2017 um 19:49 schrieb Stefan Beller:
On Mon, Jul 17, 2017 at 4:17 AM, Joachim Durchholz <j...@durchholz.org> wrote:
Hi all
I'm hacking some script that calls into git, and I need to detect whether a
repository was configured with a submodule name that will work on "git
submodule init" and friends.
There is no such a thing as "git submodule valid-name" unfortunately.
Looking through "git submodule add", I think it is safe to assume
that any string valid as a subsection in git-config is a valid submodule name.
That's what I have been thinking myself.
Our man page says:
Subsection names are case sensitive and can contain any characters
except newline (doublequote " and backslash can be included by escaping
them as \" and \\, respectively).
I am not sure about the quality of submodule shell code to handle the quotations
for double quote and backslash correctly, so I would suggest not using them,
either.
The quality is pretty dubious for path names (where I have torture tests
in place).
I haven't done these tests for module names yet. I doubt it's going to
look prettier though.
I *can* run a git init and see whether it works, but I need to be 100% sure
that the error was due to an invalid submodule name and not something else.
Bonus points for every version of git for which it works.
I do not think Git offers a universal solution across versions except actually
running "submodule init" and then making an educated guess if the error
comes from bad naming or something else.
Yeah, I think that's the way to go - clone into a local temp directory,
set up the submodule to a sane module and subdirectory name, and if that
works, test what happens with the original configuration.
I'd have preferred something less elaborate though.
E.g. SVN has a --xml option that will output everything in XML format.
(Not useful for shell scripting but easy for almost any other scripting
language.)
This sounds like you're taking user input or otherwise untrustworthy data
as submodule names?
I'm auto-downloading submodules as configured in 3rd-party repositories.
Which means untrusted data is copied to the user's home directory, so I
definitely need to make sure that nothing nasty can happen.
My current code is a /bin/sh script.
Given the security/reliability/robustness problems I keep encountering,
the temptation to rewrite this in Python has been steadily growing,
though I'm not quite there yet.
Regards,
Jo
