On 26/06/2024 19:11, Junio C Hamano wrote:

Phillip Wood [off-list ref] writes:

quoted

To expand an this a little - a couple of times I've wanted to checkout
a bare repository that is owned by a different user. It is a pain to
have to add a new config setting just for a one-off checkout. Being
able to adjust the config on the command line would be very useful in
that case.

True.  As long as it is deemed safe to honor the one-off "git -c
safe.directory=..." from the command line, for the purpose of this
"I who am running this 'git' process hereby declare that I trust
this and that repository", I think it would be the best solution
for the "git daemon" use case.

This actually works already, the behavior was changed in 6061601d9f 
(safe.directory: use git_protected_config(), 2022-07-14). The reason I 
thought it didn't work was that I remember it failing on Debian bullseye 
a few months ago but that used an older version of git. There is some 
more rationale for the change in 779ea9303a7 (Documentation: define 
protected configuration, 2022-07-14)

Best Wishes

Phillip

And it is much better than adding a one-off environment variable.
After all, if your "git daemon" user does not have a $HOME set in
its /etc/passwd entry, you cannot set such an environment variable
in $HOME/.profile so somewhere in your "git daemon" invocation would
have to be tweaked to have code snippet that sets and exports it
*anyway*.  You can tweak the "git" invocation to add the command
line tweak "-c safe.directory=..." at the place you would have set
and exported the variable, and using the well understood "git -c
var=val" mechanism would be more appropriate.

quoted

quoted

Or you could set $HOME to a suitable directory when running "git

...
The advantage of this approach is that there are no changes needed to
git, instead of setting GIT_IGNORE_INSECURE_OWNER one sets HOME to
point to a suitable config file. I found this useful when I was
debugging the issues with git-daemon earlier[1]

Yup, that sounds like a workable approach, if "git -c var=val"
approach turns out to be inappropriate for security purposes
for whatever reason.

Thanks.