`set-safe-directory: true` is not sufficient for submodules

[sdroege]

See https://github.com/gtk-rs/gtk-rs-core/pull/760 for an example where this fails.

In this repository there are some submodules that are configured with update = none, i.e. git submodule update --init --recursive is not going to fetch them. For some CI tasks we still want to have them though, so it is necessary to run git submodule update --checkout.

This does not work and fails as follows:

Run actions/checkout@v3
[...]
Adding repository directory to the temporary git global config as a safe directory
/usr/bin/git config --global --add safe.directory /__w/gtk-rs-core/gtk-rs-core
[...]
Run git submodule update --checkout
fatal: unsafe repository ('/__w/gtk-rs-core/gtk-rs-core' is owned by someone else)
To add an exception for this directory, call:

    git config --global --add safe.directory /__w/gtk-rs-core/gtk-rs-core
Error: Process completed with exit code 128.

It's unclear how to work around this as the suggested solution from the error message is clearly already done.

[sdroege]

Hmm, this was somehow caused by using a different container than the default ubuntu-latest one. Removing the container configuration makes this work as expected, which seems not intended behaviour.

[sdroege]

Unfortunately using the default docker container is not an option for all repositories where I need this. How can this be worked around?

[sdroege]

Apparently by calling git config --global --add safe.directory manually again at a later time :confused:

[ssbarnea]

That new git behavior is extra problematic if you happen to also make use of WSL, as it means that you also need to add the unix path as safe directory, not only the default workspace.

I think that is might prove more useful to try to avoid having bad file permissions on github runners by default.