Re: Bug: git config does not respect read-only .gitconfig file
- From
Jonathan Word <argoday@argoday.com>
- Date
- Nov 8, 2016, 17:18 UTC
- Message-ID
- <CAD9aWCgZkuaZNMDparVZE_WNFpOp7ud6iyCueGVbnU8s_EYtrQ@mail.gmail.com>
- In-Reply-To
- <40608c85-f870-87f7-daee-7fa98f5d19c1@jump-ing.de>
I proposed a variant that would be fully backwards-compatible (don't know who might rely on the functionality http://xkcd.com/1172/ ) however I'd be happy to see the change without additional config +1 ... that's a call for this list as maintainers.
The root of the issue is that tempfile::rename_tempfile ( https://github.com/git/git/blob/35f6318d44379452d8d33e880d8df0267b4a0cd0/tempfile.c#L288 ) relies on http://man7.org/linux/man-pages/man2/rename.2.html which, only requires directory write permissions - not file write permissions. As you point out 'rm' is another example of this paradigm and it works exactly the same way.
The point of confusion to users ( / my team) is that `git config` gives the appearance of editing / modifying the .gitconfig file in-place (where file permissions would be respected) however the actual implementation performs the equivalent of a rm+mv which only respects directory permissions.
The `git config` command is only one of many that leverage that rename_tempfile function, if opting to respect file-level permissions across the board then the desired change is probably at that level rather than in config::git_config_set_multivar_in_file_gently which would only add respect for file-level permissions to the one command.
Cheeers,
On Tue, Nov 8, 2016 at 11:49 AM, Markus Hitter <mah@jump-ing.de> wrote:
Show 25 quoted lines
> Am 08.11.2016 um 16:22 schrieb Jonathan Word:
>> Proposal:
>>
>> Part 1) Add a .gitconfig variable to respect a read-only gitconfig
>> file and optional "--force" override option for the `git config`
>> command
>>
>> Such a gitconfig variable could be defined as:
>> config.respectFileMode: [ "never", "allow-override", "always" ]
>> [...]
>> Thoughts?
>
> I'd consider disrespecting file permissions to be a bug. Only very few tools allow to do so ('rm' is the only other one coming to mind right now), for good reason. If they do, only with additional parameters or by additional user interaction. Git should follow this strategy.
>
> Which means: respect file permissions, no additional config variable and only if there's very substantial reason, add a --force. KISS.
>
> That said, disrespecting permissions requires additional code, so it'd be interesting to know why this code was added. The relevant commit in the git.git repo should tell.
>
>
> Markus
>
> --
> - - - - - - - - - - - - - - - - - - -
> Dipl. Ing. (FH) Markus Hitter
> http://www.jump-ing.de/