Mantas Mikulėnas <grawity@xxxxxxxxx> writes: > After Git 2.38 (specifically after commit 6061601d9), git no longer > honors safe.directory settings in files that are [include]'d from the > main global configuration file, even though they are shown as being in > global scope by `git config --show-scope --show-origin`. > > The docs added by > https://github.com/git/git/commit/779ea9303a7de3d618f3b0e329ebb89529ab3285 > only talk about scopes and do not mention anything about [include] > being specifically ignored. > > $ git config --get-all --show-scope --show-origin safe.directory > global file:/home/grawity/.config/git/config /srv/this.works > global file:/home/grawity/.config/git/config.local /srv/this.does.not.work > > # ~/.config/git/config (owned by grawity:users) > [safe] > directory = /srv/this.works > [include] > path = ~/.config/git/config.local > > # ~/.config/git/config.local (also owned by grawity:users) > [safe] > directory = /srv/this.does.not.work > > -- > Mantas Mikulėnas CC-ed some folks who have interest in safe.directory and/or have looked at the safe.bareRepository series. Thanks for the report. As the author of the series in question, this wasn't an intended change. Protect config, as implemented in 5b3c650777 (config: learn `git_protected_config()`, 2022-07-14), reads from a hardcoded set of file paths without considering "include"s, so this bug is not surprising in retrospect. I believe this can be fixed by replacing this implementation with an invocation to config_with_options() (which knows about "include"s) should be adequate to fix this. I'll prioritize a test and a fix for this.
