Well, depending on exactly how much this blocks, this could get pretty awkward -- typing 'git log' in a repo owned by someone else can be awfully handy, even if file system permissions block changing it at all, and putting together a list of all places you might want to do this in advance could get pretty awkward. (Not running hooks, or allowing operations that would trigger them, from non-owned directories would preserve some of this usage, and still at least mitigate the dangerous cases somewhat.)
It's also not entirely clear to me what this does to site-wide shared remotes, though I suppose if they can be listed in system config, it's at least not a per-user hassle.
I do this quite often, actually. I have my NixOS system config officially stored in /etc/nixos/ and owned by root. I have a clone that lives in my home directory for WIP changes, but builds always run out of the official copy. Sometimes it’s convenient to quickly run some read-only commands directly in the official copy
Ultimately you own that repository so just set it as safe in your config. Similarly if you are looking at a coworker’s repository then you can probably trust them. It’s only when you start sharing a computer with people that you don’t really know that you have a problem.
Yes I’ve run “git status”, “git log” and “git diff” on other people’s repo’s plenty of times to help debug things, so it’d be sad to see this stop working. It seems some basic readonly operations should still be supported.
It doesn't even have to be a repo. I do git diff --no-index all the time on arbitrary files, because it's simply configured the way I want, unlike some default diff or whatever command, that I don't even remember how to properly use.
Yeah, it does seem to be very limiting. The previous behavior of allowing it can be configured by safe.directory[0].
In lack of CI I still tend to do builds in a container from a separate local user with read-only permissions. I wish they'd add an option to allow it when the user is in the owner group, which could be a decent compromise.
I kindof agree with you, but if you go to a university lab then you will likely find that all the students are all in the same groups. You don’t really want to blindly trust the group that way.
It's also not entirely clear to me what this does to site-wide shared remotes, though I suppose if they can be listed in system config, it's at least not a per-user hassle.