Remove LocalGitConfigSource

^{Originally posted by **sfayer** November 7, 2025}
Hi,

We're working on the non-k8s diracx container deployment recipe and have run into some issues with loading the CS store... We've exported our existing CS into the diracx format and have it in a local git repo directory which we're initially bind mounting in as a read-only mount at /cs_store and setting `DIRACX_CONFIG_BACKEND_URL="git+file:///cs_store?branch=master"`.

This doesn't work: The git+file handler runs into a number of issues:
- The bind mount point files are owned by "root", whereas the diracx container uses "mambauser" which trips out git's insecure file permissions check for the rev-parse command: https://github.com/DIRACGrid/diracx/blob/c265a47363850662502bb7f0fb8ebbbe94893e85/diracx-core/src/diracx/core/config/sources.py#L251-L252
- If we bypass the security checks, the checkout fails because we made it a bare repo.
- If we convert it to a normal repo, the checkout fails because the volume is read-only.
- If we make the volume read-write, the checkout fails because of the different file ownership.

We modified the code, to use the git+https "RemoteGitConfigSource" handler for the git+file case too and this works (and I suspect would also work better if this directory was shared across multiple hosts).

Our questions for discussion are:
- Is there actually a good use case for the LocalGitConfigSource class? It seems to me that in the majority of deployments RemoteGitConfigSource would work the same or better, even if the source is actually a local directory.
- If removing LocalGitConfigSource isn't an option, perhaps we could make using it optional instead? (For example offering 3 protocol types, say git+https and git+file using RemoteGitConfigSource and a new git+local option if you really want the LocalGitConfigSource behavior)?

We're not really sure how this is all going to work out if it needs to start pushing commits back: Getting the permissions all correct for writing a bind-mount on any platform seems to be its own challenge (but perhaps that isn't planned for a while and we can worry about that later?).

Regards,
Simon

Mentioning @marianne013