On Mon, Sep 7, 2020 at 7:06 PM Drew DeVault <sir@xxxxxxxxx> wrote: > > The basic idea is that the server could advertise some config options > which it recommends the client sets for a given repo after a fetch. Some > possible use-cases for this feature include setting: > > - format.subjectPrefix to 'PATCH my-project' > - sendemail.to to the mailing list address > - push.pushOption to recommended push options It could be useful to suggest promisor/partial clone remote config options too. > Upon cloning, each recommended config option would be displayed to the > user, and they would be prompted ([Y/n]) to agree to set that value in > the config file for that repository. Maybe the default should be "N" instead of "Y" for more security. Also when not using a terminal, it should do nothing by default too. > Additionally, there would be a > config option which white-lists a list of config options which are > automatically agreed to without prompting, This might be dangerous if this option can also be proposed by the server, as it could first propose a big list of white listed options to the client. > and each config option would > have one of the following states: > > - accept-silent: set the option without printing a message > - accept-verbose: set the option and display a message > - prompt: prompt the user to set this config option > - reject-silent: silently refuse to set this config option > - reject-verbose: refuse to set this config option and display a message > > We would default to reject-verbose for all unknown config options and > include a set of defaults which specifies the appropriate trust level > for various useful benign options (such as the examples above). > > The implementation would involve advertising config-advertisement in the > fetch protocol. Both the client and server would have to agree to use > it. If the server supports it but the client does not (in the case of an > old client), it could fall back to printing the list of recommended > options to stderr. > > To choose which config options to advertise, a new option would be > introduced (uploadpack.advertiseOptions) for example, which has a list > of .git/config options from the remote repository to forward to the > client. > > This would be a lot of work so I'd like to float it for discussion > before getting started. What do you guys think? My opinion is that you might not want to start working on all the above at once. It might be better to start small and safe while leaving the door open to further improvements.
